Человечек идёт на повышение
Другие наши проекты: https://t.me/+1s1ZEg7EeQ5mNDVi
Другие наши проекты: https://t.me/+1s1ZEg7EeQ5mNDVi
Интересно как-то у меня выходит - мои пет проекты получаются случайно. Нет финальной цели, есть только импульс: "О! А это звучит интересно, как же это можно сделать?". И все: "сон для слабаков", "пиво в пятницу? конечно не буду!" и все в таком духе. Как говорится - есть только путь. И это история началась примерно так же... Вечерело На работе мне было нечем заняться, нужно было поставить некоторое количество серверов и сервисов на мониторинг, но из-за большой бюрократии в компании сделать это было не просто, да и сама мониторинговая система работала на базе SNMP, вот только где взять SNMP у самописного сервиса? И тут в голову пришла гениальная идея попробовать самому. К тому же сложным это не выглядело: мониторинг портов, http и куда-нибудь отправить алерт. "Почему бы и не да" - подумал я, к тому же больше познаю Python. И так появился он...
Простенький мониторинг, который как-то, что-то делает, что-то показывает и даже консольная тулза есть:
Спустя пару лет я вспомнил о том, что у меня был самопальный мониторинг и почему бы его не добавить в мой основном пет проект, в Roxy-WI. Сказано - сделано. Ведь чем больше функций тем лучше! И так получилось, что со временем мониторингу стало "тесно" в стенах Roxy-WI: с одной стороны надо развивать веб интерфейс, с другой мониторинг, чтобы не было перевеса в одной из сторон я решил вынести мониторинг в отдельный проект. Приветствуйте - RMON! Да... с именами у меня так себе.
RMON история проверок
Пф... еще один мониторинг, какой уже по счету?
100500? Да, пожалуй так, так же наверное говорили про Prometheus в свое время: "Зачем ведь есть Zabbix?!", а до этого и про Zabbix: "Зачем ведь есть SNMP, MRTG и Nagios?!". Да, есть, но почему нет? Вдруг получится сделать в чем-то лучше. Конечно я пока не ставлю RMON в ряды с этими системами мониторинга, пока не ставлю. А вдруг получится сделать чем-то лучше ;)?
В чем я вижу "конкурентное преимущество" RMON над существующими системами мониторинга, прежде всего над Prometheus (как промышленный стандарт) и Uptime Kuma (как более близкий по функционалу)? Основных, киллер фич, как по мне, минимум пять:
Агенты - можно установить несколько штук как внутри периметра, так и снаружи и мониторить доступность из нескольких точек. Агенты можно объединять в "регионы" для балансировки чеков, шарить между группами.
API.
Ролевая модель доступа к агентам.
Простота установки и настройки, Web интерфейс и Status pages.
7 метрик HTTP соединения + мониторинг протухания SSL серта.
Так же есть мониторинг Ping-ом, DNS записей и TCP. В будущем планирую расширять возможности проверок.
Мы все это уже видели
Да, агенты по сути реализованы в Prometheus и Blackbox exporter: Blackbox exporter-ы тоже можно поставить в разных точках и мониторить от туда, +- тоже самое. Да, Uptime Kuma даже легче поднимается и тоже имеет web интерфейс. API можно заменить тем же Ansible, например. Но есть одно но - этого нет и там и там. Нельзя отдать playbook человеку и сказать: "Вон на тех экспортерах ничего не создавай, тебе низя!", надо будет поднимать несколько инстансов, чтобы разделить доступ, плюс его надо обучить работать с Ansible. А еще нельзя автоматизировать работу с проверками. Точнее скорей всего можно, но это костыли и высокий уровень входа.
Как итог и тем кто будет писать: "Web отстой, консоль наше все!"
Да, временами так и есть, а временами - нет. Порой даже самые передовые и технологически правильные решения не подходят. Где-то жалко тратить время и ресурсы, где-то неохота погружаться, а где-то надо "через 2 минуты, чтобы все было". А временами передовые решения просто не нужны и удобней работать с тем что попроще. Надо исходить из конкретной ситуации, а не загонять всех в рамки: "%UserName%, используй только %ProgrameName% во всех случаях жизни!".
P.S. если захотите попробовать, то пишите, с удовольствием покажу/объясню :).
Курсы - это очень здорово, сегодняшняя ситуация с курсами создаёт по-настоящему особенный взгляд на мир:
Из одного там профильного чатика
(Главное не дожить! Главное не дожить!)
Расскажите что вы из IT не говоря что вы из IT.
Когда решил стать фронт разРАБом но освоил только CSS и HTML ..
Знакомы ли вам ситуации, когда ваши коллеги на работе увлеченно обсуждают доки, контейнеры и архитектуру? Мы что в порту? -подумаете вы..
Сегодня мы раскроем завесу этой тайны и научим вас понимать язык DevOps.
Друзья, перед тем как углубиться в тему Docker и контейнеризации, рекомендуем подписаться на канал Telegram "Самоучки IT (Управление проектами)" https://t.me/+NfVrLMxdKS0yNDNi . Этот канал охватывает широкий спектр тем, связанных с управлением IT-проектами, DevOps и многим другим.
Представьте, что ваш коллега-разработчик написал программу на одном из языков программирования, запустил ее в своем дистрибутиве Linux, добавил множество дополнительных программ, необходимых для запуска, и теперь вам нужно все это запускать, интегрировать с другими частями вашего общего приложения и предоставлять клиентам. Как скопировать все необходимое для работы программы, чтобы ее можно было запускать везде и она работала одинаково?
Одним из решений могут быть виртуальные машины (ВМ). Если вы не знакомы с этим термином, то вкратце это как будто бы вы создали еще один компьютер внутри вашего компьютера. В этой схеме у нас есть наш сервер, на нем установлена операционная система (ОС), а поверх нее работает гипервизор, например, Hyper-V, VMware ESX или VirtualBox, который эмулирует железо и управляет виртуальными машинами. Каждый экземпляр ВМ имеет собственную ОС, которая называется гостевой, и приложения работают уже внутри нее. Таким образом, вы можете на одном сервере запускать множество разных ОС и приложений.
Однако в современных реалиях, когда все любят разбивать одну большую программу на множество маленьких и называть это микросервисной архитектурой, такой подход может быть не очень оптимальным. Ведь каждая ВМ запускает у себя отдельную ОС, что может работать медленно и требовать много ресурсов.
Здесь нам приходит на помощь Docker. Это такой инструмент, который упаковывает код приложения, системные инструменты, среду выполнения, библиотеки, зависимости и файлы конфигурации, необходимые для его запуска, в виртуальный контейнер, который может работать на любом компьютере, где установлен Docker. Это похоже на контейнер с грузами в порту, который можно удобно перемещать и запускать на любом судне.
Docker работает похожим образом с ВМ, но есть одно ключевое отличие. С Docker мы избавляемся от гипервизора, а вместо того, чтобы виртуализировать железо, мы виртуализируем только ОС. Это значит, что нам не нужны отдельные копии ОС для каждого контейнера, потому что контейнеры используют ядро ОС того сервера, где мы работаем, при помощи приложения Docker Engine. Это позволяет нам экономить ресурсы и удобно работать с изолированными контейнерами.
При этом приложения остаются все так же изолированы от системы и других приложений. Кстати, Docker не единственная технология контейнеризации, но определенно самая популярная.
Давайте теперь поговорим о самом Docker. Здесь нужно знать о трех основных элементах: Dockerfile, образ и контейнер. Взаимодействие между ними такое: из Dockerfile собирается образ, а на основе образа запускается контейнер.
Наша начальная точка - это Dockerfile, который содержит код, являющийся набором инструкций, которые говорят Docker, как нужно создать образ и что там должно оказаться. А образ — это уже готовое к запуску приложение, в котором лежит исходный код, библиотеки, зависимости, инструменты и другие файлы, необходимые для его запуска. И уже из этого образа мы запускаем сам контейнер, экземпляр нашего приложения.
Образы приложений можно делиться для этого используются Docker-репозитории. Самый крупный - это Docker Hub, откуда можно скачать образ какого-нибудь приложения или ОС и на их основе собирать свой собственный образ.
Давайте рассмотрим это на примере. Создадим Dockerfile и напишем в нем следующее:
Это значит, что мы берем за основу существующий образ Ubuntu версии 20.04, устанавливаем веб-сервер nginx, открываем порт 80 и запускаем сервер при старте контейнера.
Сохраним этот файл и создадим из него образ при помощи команды docker build. В этот момент Docker пройдется по всем нашим инструкциям шаг за шагом и создаст для нас образ, который будет содержать все, что мы указали в Dockerfile.
После создания образа можно запустить из него контейнер, выполнив команду docker run. Теперь, если мы откроем браузер и наберем в адресной строке localhost, то увидим, что все работает.
Вот так просто, используя различные команды, мы можем создавать и запускать свои контейнеры. Однако, если нам не требуется сложная настройка образа, а нужно просто получить работающую программу, то мы можем скачать готовый образ из Docker Hub и запустить его, выполнив команду docker pull и docker run.
Конечно, в реальности все обычно сложнее и приходится решать множество нестандартных задач, например, как сохранить данные при остановке контейнера или как связать несколько контейнеров в единое приложение. Для этого используются различные инструменты и технологии, такие как Docker Compose, Kubernetes и другие.
Подводя итоги, можно сказать, что Docker - это не только модное слово, которое поможет повысить вашу зарплату, но и мощный инструмент, который объединяет в себе все, что нам нравится в IT: автоматизацию, скорость, консистентность, модульность, экономичность и классный логотип.
И если вы еще не знакомы с Docker, то пора исправить это. Ну и под конец вопрос к знатокам. Если докер такой классный, то почему он до сих пор не выдавил с рынка виртуальные машины? В каких задачах без виртуалок не обойтись?
Для получения дополнительных знаний и инсайтов в области управления IT-проектами, DevOps и смежных тем, рекомендуем подписаться на канал Telegram "Самоучки IT (Управление проектами) https://t.me/+NfVrLMxdKS0yNDNi
В этой статье я расскажу вам о концепции CI/CD, которая является неотъемлемой частью современной разработки программного обеспечения.
Сегодня порассуждаем про концепцию CI/CD, которая ныне на пике популярности в разработке софта.
Также найти множество интересной и полезной информации вы можете на канале Самоучки IT (Управление проектами) https://t.me/+NfVrLMxdKS0yNDNi
CI/CD - это Continuous Integration, Continuous Delivery - непрерывная интеграция, непрерывная поставка. Это одна из DevOps-практик, которая также относится к Agile-подходу. Автоматизация развёртывания позволяет разработчикам сфокусироваться на реализации бизнес-требований, качестве кода и безопасности.
В чем фишка? Это автоматизированный конвейер, который цепляет только что написанный код к главной кодовой базе, гоняет всякие тесты и автоматом деплоит обновлённую версию.
Многие ошибочно думают, что CI и CD - разные процессы. Но на самом деле они связаны как матрёшки. Внутри - непрерывная интеграция, снаружи - непрерывная доставка. Основная их цель - увеличить стабильность выпусков и ускорить весь этот процесс.
Давайте по-полочкам разберём этапы CI/CD цикла:
Код . На этом этапе идёт написание кода, покрытие его тестами, commit и push в систему контроля версий
Сборка. Система вроде Jenkins автоматически собирает ваши изменения и запускает их тестирование.
Тестирование. После успешного прохождения автоматических тестов изменения отдаются на ручное тестирование.
Релиз. После того, как команда тестировщиков проверила все изменения, у нас получается стабильная версия продукта – релиз-кандидат.
Деплой. Релизную ветку мы загружаем и разворачиваем на продакшен-сервере клиента.
Мониторинг. Следим за развёрнутой версией продукта и в случае проблем стабилизируем её или фиксим.
Планирование. Планирование новой функциональности или внесение изменений для будущих релизов.
Теперь разберем, как CI/CD помогает автоматизировать эти шаги.
Непрерывная интеграция — это автосборка и тестирование всего кода в общем репозитории после слияний. Команды часто используют feature flags или ветки для контроля готовности функционала. CI позволяет выявлять проблемы до деплоя кривого кода на прод.
На этапе сборки упаковываются все компоненты ПО и БД. Запускаются модульные, функциональные, регрессионные тесты и другие виды тестов для проверки стабильности. Это непрерывное тестирование - важная часть CI/CD.
Следующий этап - непрерывная поставка. Тут автоматизируется процесс подготовки релиза к деплою после CI. Настраиваются параметры окружений, выполняются необходимые запросы для перезапуска сервисов и т.д. DevOps команда берет протестированный релиз и выполняет все действия для деплоя на проде в пару кликов.
Финальный шаг - непрерывное развертывание (CD). Он включает все предыдущие шаги и суть его в том, чтобы развернуть изменения программиста в продакшене без дополнительных действий. Но для этого в команде должна быть культура мониторинга, чтобы в случае проблем можно было оперативно откатить изменения.
Ещё один важный момент - CI/CD конвейеры широко используются с Kubernetes и бессерверными архитектурами. Контейнеры позволяют стандартизировать упаковку, упрощают масштабирование окружений. А бессерверные вычисления типа AWS Lambda интегрируются в конвейеры через плагины.
В компаниях, где CI/CD внедрён, часто улучшаются ключевые DevOps метрики: частота деплоев, lead time для изменений, время восстановления после инцидентов. Но для этого нужно наладить весь процесс по методологии DevOps.
В общем, CI/CD - мощная практика для автоматизации разработки и деплоев. Команда разработчиков просто пишет код, а остальные шаги в конвейере выполняются на автомате. Такой подход экономит время и обеспечивает стабильность ПО.
А чтобы все это не было просто сухой теорией, расскажу реальный кейс из жизни.
Однажды мне довелось поработать в одной прогрессивной конторе, где CI/CD был поставлен на самом деле очень грамотно.
Команда разработчиков активно писала код в feature branches регулярно создавая pull request, для слияния изменений в мастер-ветку. После каждого такого merge автоматически запускался конвейер CI. Система типа Jenkins забирала новый код, собирала приложение, гоняла batch -тестов - юнит, интеграционные, регрессионные. Все это не занимало больше 10 минут.
Если все тесты проходили успешно, включался следующий этап - непрерывная поставка. Сборка артефактов, подготовка всех зависимых сервисов, настройка тестовых окружений — все это выполнялось автоматически конвейером. Разве что DevOpsы мониторили процесс на предмет ошибок.
Но самое крутое начиналось дальше. После успешной поставки в тест-окружения запускалась финальная стадия - непрерывное развёртывание. Конвейер автоматически деплоил собранную версию на продакшен сервера, обновлял контейнеры, переключал трафик, и свежая фича становилась доступной всем пользователям!
Согласитесь, это было очень круто - от написания строчки кода до релиза проходило всего минут 30 максимум, если все шло штатно. При этом человеческое вмешательство требовалось только на самом старте - commit изменений. Остальным занималась магия CI/CD.
Плюс в углу офисной площадки красовался большой ТВ-экран, где транслировался статус всех активных сборок и деплоев - кто закоммитил (committed), на какой стадии идёт процесс, есть ли ошибки. Так что любой мог присмотреться если что пошло не так.
В общем, навороченный CI/CD конвейер сильно упрощал жизнь разработчикам и DevOpsам, позволяя много времени сэкономить на рутинных задачах поставки кода на прод. Да и со стабильностью системы не было никаких проблем благодаря повсеместному тестированию. Так что если доведёте CI/CD до ума, то только в плюсе будете!
Ну что? Я надеюсь, теперь у вас более-менее все встало на свои места с этой концепцией. Оставляйте свои мнения и кейсы в комментах. Будем продолжать разбираться в крутых IT-темах на канале Самоучки IT(Управление проектами)https://t.me/+NfVrLMxdKS0yNDNi