container agent2 не установлено что это значит

Мониторинг Docker с помощью Zabbix Agent 2

Несколько релизов назад у Zabbix был анонсирован новый агент, расширяющий свой функционал с помощью плагинов. Сегодня я рассмотрю, как с помощью Zabbix Agent 2 настроить мониторинг контейнеров Docker, используя базовый шаблон. Заодно и посмотрю, что из себя представляет новый агент.

Введение

Ранее я уже делал заметку по поводу Zabbix Agent 2, где перечислил основные отличия от прошлого агента. Их там много, так что рекомендую ознакомиться, прежде чем продолжать. Со временем развитие будет получать именно 2-я версия, а старый агент будет просто поддерживаться в том виде, как он есть сейчас. Новый функционал в него уже не будут завозить.

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

То же самое на Debian 10, если предпочитаете его:

Установка Zabbix Agent 2

На хост, где крутятся Docker контейнеры, которые мы мониторим, надо установить Zabbix agent. Установка будет зависеть от системы хоста, но в общем случае это просто подключение нужного репозитория и установка через пакетный менеджер.

На момент написания статьи, последней версией Zabbix была 5.4, так что показываю, как установить Zabbix Agent 2 именно этой версии.

Centos 8 и другие rpm-based дистрибутивы:

Делаем базовую настройку агента. Добавляем в конфиг /etc/zabbix/zabbix_agent2.conf информацию о сервере и имени хоста.

Перезапускаем zabbix-agent2 и добавляем в автозагрузку.

Дополнительно нам нужно добавить пользователя zabbix, от имени которого работает агент, в группу docker, чтобы у него был доступ к docker.sock.

После этого надо перезагрузить хост, чтобы изменения вступили в силу. Если этого делать не хочется или нет возможности, можно напрямую выдать права.

Теперь переходим на сервер мониторинга Zabbix. Дальнейшая настройка будет проходить там.

Настройка мониторинга Docker

Первым делом зайдём в консоль Zabbix сервера и убедимся, что он корректно может забирать данные о Docker с наблюдаемого хоста. Для этого воспользуемся утилитой zabbix_get.

Если получите ошибку:

ZBX_NOTSUPPORTED: Cannot fetch data: Get http://1.28/info: dial unix /var/run/docker.sock: connect: permission denied.

Возвращайтесь на хост с агентом и docker и проверяйте права доступа пользователя zabbix к сокету докера. Выше я показал, что надо сделать.

Если всё в порядке с доступом, то переходите в web интерфейс сервера мониторинга. Нам нужно добавить к наблюдаемому хосту с Docker соответствующий шаблон. Называется он Docker by Zabbix agent 2.

Если у вас его нет, как это было у меня, то скачайте свежую версию шаблона. Вам нужно выбрать файл template_app_docker.yaml и сохранить его исходный код в какой-то файл, чтобы потом импортировать на сервер Zabbix. Не забудьте указать расширение yaml, иначе импорт не заработает.

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

После этого в элементах данных появятся контейнеры и связанные с ними айтемы. В Последних данных можно смотреть метрики по тэгу Application: Docker.

В шаблоне присутствуют следующие триггеры:

Так же в шаблоне есть следующие графики:

Заключение

Сколько бы Zabbix не хоронили, но он живее всех живых и развивается в правильном направлении. С его помощью нет никаких проблем в настройке мониторинга Docker, несмотря на то, что это динамически изменяемая среда. Все изменения отслеживаются и мониторинг настраивается автоматически. Участие оператора не требуется. Достаточно один раз все сделать. Причем допиливать что-то тоже нет необходимости. Всё работает из коробки с помощью штатного функционала.

Источник

KLMS Agent что это за программа на Андроиде?

Всем привет Поговорим о том что такое KLMS Agent (com.samsung.klmsagent), моя цель сегодня как всегда проста, это собрать максимум инфы о KLMS Agent и написать все это здесь так, чтобы вам было сразу все понятно. Ну что, начинаем, пошел я значит копать интернет… Ну и как всегда ребята, инфы оч мало и приходится сложно. Значит о том что такое KLMS Agent я пока ничего не нашел кроме того, что данное приложение относится к KNOX. Ничего не остается мне как узнать что такое KNOX. Пошел копать..

Ну и вот что я узнал, короче вся эта тема идет от фирмы Самсунг. Но что такое KNOX? Значит как говорит сама компания Самсунг, KNOX это мобильное решение для работы предприятий. Звучит громко и немного бредово. Читаю дальше, пишется что KNOX это типа решение для усиления безопасности Андроида, типа защита от каких-то сбоев и несанкционированного доступа к данным. Короче ребята, там еще кое что написано, но поверьте мне, что все это вам интересно не будет. Одним словом KNOX это какое-то фирменное ПО от Samsung для безопасности данных. Не знаю нужное ли это все, однако факт того что умельцы делают прошивки где полностью выпиливают KNOX из системы как бэ намекает…

Компания Самсунг вроде думает как сделать так чтобы KNOX нельзя было выпилить из телефона..

Ага ребята! Вроде все стало понятно. Короче KNOX это такая штука которая обеспечивает безопасную работу приложений, которые используются на предприятиях. Короче все, делаем вывод: KNOX относится к безопасности. Мало того, не знаю правда это или нет, но вроде бы KNOX будет платным или уже есть.. Еще есть такая инфа что даже министерство обороны США будет использовать KNOX, тут даже не знаю что сказать, все так серьезно…

Вот я нашел картинку, это сведенья о приложении KLMS Agent, тут версия идет 1.5 (у вас может быть другая):

Тут можно было бы остановить приложение ну или отключить, но как видите кнопки для этого тут не активны. У вас может быть активны, но наверно тоже неактивны. Галочку вроде тоже снять нельзя, ну чтобы не было уведомлений. То есть могу предположить, что для того чтобы отключить KLMS Agent, нужно иметь root-доступ, ну а это требует уже неких знаний. Root-доступ это не шутки, нужны знания

Хм, на форуме 4PDA нашел интересную инфу. Получается что KNOX это не совсем как бы относится к безопасности. Я не буду писать своими словами что я там прочитал, лучше вы это тоже сами почитайте, весьма познавательно, вот что пишет по этому поводу юзер KlonDike на форуме:

Есть сведенья что к KNOX относится не только KLMS Agent но и ELM Agent, во как

Нашел еще одну инфу на форуме 4PDA, вот можете сами посмотреть что пишет юзер под ником Муррр:

Еще может быть такое, что откроется KLMS Agent и там будет запрос о том что вы соглашаетесь с тем что KNOX будет следить за безопасностью устройства, хм хм…

Как я вроде понимаю, то если KNOX удален, то KLMS Agent ничего не делает, то есть можно удалить и его, но я не знаю возможно ли вообще это.

Также узнал что через KLMS Agent могут некоторые программы получать какую-то лицензию.

Короче такие дела ребята. Запарился искать инфу которой нет. KLMS Agent это от KNOX идет и я думаю что удалять нет смысла, ибо если вы простой юзер, то просто так вы не удалите. А чтобы грамотно удалить KNOX и все что касается этого то нужно быть ну я думаю спецом, понимаете? А то если не знаете и будете делать, просто можете напартачить и телефон еще не включиться, ну мало ли, короче я вас предупредил…

Вот нашел интересную картинку, тут показана корзина (Recycle bin):

И вот в этой корзине как видите есть KNOX, Knox Notification Manager, KNOX SetupWizardClient.. То есть у кого-то это получилось все таки удалить

Ребята, кстати, вот что еще хочу вам сказать. Вообще существуют так называемые кастомные прошивки, где уже много ненужного выпилено, вот такую прошивку можно поставить на смартфон, в теории сам смарт даже работать должен быстрее (наверно). Но опять же чтобы поставить прошивку самому нужно немного шарить в этом деле, а то можно натворить делов то..

А вот вся семейка KNOX в сборе:

А тут их еще больше…, это вообще капец:

Ну что ребята, будем заканчивать. Надеюсь что вам тут все было понятно, ну а если что не так, прошу простить, я знаю что написал инфы мало, но блина ее вообще нету. Удачи вам и всех благ

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

Источник

Учимся разворачивать микросервисы. Часть 4. Jenkins

Это четвертая и заключительная часть серии статей «Учимся разворачивать микросервисы», и сегодня мы настроим Jenkins и создадим пайплайн для микросервисов нашего учебного проекта. Jenkins будет получать файл конфигурации из отдельного репозитория, собирать и тестировать проект в Docker-контейнере, а затем собирать Docker-образ приложения и пушить его в реестр. Последней операцией Jenkins будет обновлять кластер, взаимодействуя с Helm (более подробно о нем в прошлой части).

Ключевые слова: Java 11, Spring Boot, Docker, image optimization

Ключевые слова: Kubernetes, GKE, resource management, autoscaling, secrets

Ключевые слова: Helm 3, chart deployment

Настройка Jenkins и пайплайна для автоматической доставки кода в кластер

Ключевые слова: Jenkins configuration, plugins, separate configs repository

Jenkins — это сервер непрерывной интеграции, написанный на Java. Он является чрезвычайно расширяемой системой из-за внушительной экосистемы разнообразных плагинов. Настройка пайплайна осуществляется в декларативном или императивном стиле на языке Groovy, а сам файл конфигурации (Jenkinsfile) располагается в системе контроля версий вместе с исходным кодом. Это удобно для небольших проектов, однако, часто более практично хранить конфигурации всех сервисов в отдельном репозитории.

Код проекта доступен на GitHub по ссылке.

Установка и настройка Jenkins

Установка

Существует несколько способов установить Jenkins:

War-архив с программой можно запустить из командной строки или же в контейнере сервлетов (№ Apache Tomcat). Этот вариант мы не будем рассматривать, так как он не обеспечивает достаточной изолированности системы.

Устранить этот недостаток можно, установив Jenkins в Docker. Из коробки Jenkins поддерживает использование докера в пайплайнах, что позволяет дополнительно изолировать билды друг от друга. Запуск докера в докере — плохая идея (здесь можно почитать почему), поэтому необходимо установить дополнительный контейнер ‘docker:dind’, который будет запускать новые контейнеры параллельно контейнеру Jenkins’а.

Также возможно развернуть Jenkins в кластере Kubernetes. В этом случае и Jenkins, и дочерние контейнеры будет работать как отдельные поды. Любой билд будет полностью выполняться в собственном контейнере, что максимально изолирует выполнения друг от друга. Из недостатков этот способ имеет довольно специфичную конфигурацию. Из приятных бонусов Jenkins в Google Kubernetes Engine может быть развернут одним кликом.

Хоть третий способ и кажется наиболее продвинутым, мы выберем прямолинейный путь и развернем Jenkins в Docker напрямую. Это упростит настройку, а также избавит нас от нюансов работы со stateful приложениями в Kubernetes. Хорошая статья для любопытствующих про Jenkins в Kubernetes.

Так как проект учебный, то мы установим Jenkins на локальной машине. В реальной обстановке можно посмотреть в сторону, например, Google Compute Engine. В дополнение замечу, что изначально я пробовал использовать Jenkins на Raspberry Pi, но из-за разной архитектуры «малинки» и машин кластера они не могут использовать одни и те же Docker-образы. Это делает невозможным применение Raspberry Pi для подобных вещей.

После установки Jenkins открываем http://localhost:8080/ и следуем инструкциям. Настроить Jenkins можно через UI, либо программно. Последний подход иногда называют «инфраструктура как код» (IaC). Он подразумевает описание конфигурации сервера с помощью хуков — скриптов на Groovy. Оставим этот способ настройки за рамками данной статьи. Для интересующихся ссылка.

Плагины

Для нашего проекта нам понадобится установить два плагина: Remote File Plugin и Kubernetes CLI. Remote File Plugin позволяет хранить Jenkinsfile в отдельном репозитории, а Kubernetes CLI предоставит доступ к kubectl внутри нашего пайплайна.

Установка Helm

Глобальные переменные среды

Так как у нас два сервиса, то мы создадим два пайплайна. Некоторые данные у них будут совпадать, поэтому логично вынести их в одно место. Это можно сделать, задав глобальные переменные среды, которые будут установлены перед выполнением любого билда на сервере Jenkins. Отмечу, что не стоит с помощью этого механизма передавать пароли — для этого существуют секреты.

Секреты

В предыдущей части в файле NOTES.txt нашего чарта мы описали последовательность команд для получения токена сервисного аккаунта. Вывести эти команды для кластера можно, запросив статус Helm-инсталляции ( helm status msvc-project ).

Конфигурация пайплайна

Как уже было упомянуто ранее, пайплайны описываются на Groovy, и могут быть написаны в декларативном и императивном стилях. Мы будем придерживаться декларативного подхода.

В Jenkins процесс выполнения пайплайна (билд) поделен на ряд шагов (stage). Каждый шаг выполняется определенным агентом (agent).

Наши пайплайны будут состоять из следующих шагов:

Структура файла конфигурации

Файл конфигурации будет иметь следующую структуру:

Агенты в Jenkins подчиняются типичным правилам «наследования» — если в шаге не определен агент, то будет использован агент родительского шага. Тег pipeline может рассматриваться как корневой шаг для всех остальных. Корневой шаг мы используем для объявления переменных среды и опций, которые по тому же правилу наследования будут иметь силу для всех вложенных шагов. Поэтому для тега pipeline установлен агент ‘none’. Использование этого агента подразумевает, что вложенные шаги обязаны переопределить этот агент для выполнения каких-либо полезных действий.

Агент в шагах Push Images и Trigger Kubernetes равен ‘any’. Это значит, что шаг может быть выполнен на любом доступном агенте. В простейшем случае это означает выполнение в контейнере Jenkins’а. Также эти шаги будут выполнены только для коммитов в мастер-ветку ( when < branch 'master' >).

Далее мы более пристально посмотрим на каждый из шагов, а также на блоки options и environment.

Опции

Блок опций может быть использован для настройки выполнения пайплайна или же отдельного шага. Мы используем следующие опции:

skipStagesAfterUnstable заставит Jenkins сразу прервать билд, eсли тесты были провалены. Поведение по умолчанию предусматривает установку статуса билда в UNSTABLE и продолжение выполнения. Это позволяет в сложных случаях более гибко обрабатывать подобные ситуации.

skipDefaultCheckout отключает автоматический чекаут репозитория проекта. Дефолтно Jenkins делает force чекаут репозитория для каждого шага с собственным агентом (в нашем случае Prepare Checkout, Push images и Trigger Kubernetes). То есть по сути затирает все изменения. Это может быть полезно при использовании пайплайна с несколькими различными образами. Однако нам нажно получить исходники с репозитория только единожды — на шаге Build. Применив опцию skipDefaultCheckout, мы получаем возможность произвести чекаут вручную. Также стоит заметить, что Jenkins будет автоматически переносить артефакты между шагами. Так, например, скомпилированные исходники из шага Build будут полностью доступны в шаге Test.

Переменные среды

Переменные среды могут быть также объявлены как для всего пайплайна, так и для отдельного шага. Их можно использовать, чтобы вынести какие-то редкоизменяемый свойства. В этом блоке мы определим имя файла докера и имена создаваемых Docker-образов.

В предыдущих статьях при работе с кластером мы всегда использовали наиболее свежие latest образы, но напомню, что это не лучший вариант из-за проблем при откатах к предыдущим версиям. Поэтому мы предполагаем, что в начальный момент времени кластер создается из самых свежих образов, а потом уже будет обновляться на конкретную версию. Тег IMAGE_TAG будет зависеть только от номера билда, который можно получить из предустановленной глобальной переменной среды BUILD_NUMBER. Таким образом наши версии будут составлять монотонную последовательность при условии того, что пайплайн не будет пересоздаваться (это приведет к сбросу номера билда). При неуспешных билдах BUILD_NUMBER также будет инкрементирован, следовательно последовательность версий образов может содержать «пробелы». Основное преимущество такого подхода к версионированию — его простота и удобство восприятия человеком. В качестве альтернативы можно подумать об использовании метки времени, чексуммы коммита или даже внешних сервисов.

Компиляция, тестирование, сборка

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

В фазе тестирования командой junit ‘**/target/surefire-reports/TEST-*.xml’ мы указываем Jenkins’у на файл с результатами тестов. Это позволит их отобразить прямо в веб-интерфейсе.

На последнем шаге мы генерируем jar-архив с нашим приложением.

Создание и отправка Docker-образа в реестр

На следующем шаге мы должны собрать Docker-образы и запушить их в реестр. Мы будем делать это средствами Jenkins, но в качестве альтернативы можно реализовать это и с помощью Maven-плагина.

Для начала нам надо доработать докер-файлы наших сервисов, которые мы разработали в первой статье цикла. Эти докер-файлы собирали приложение из исходников прямо в процессе создания образа. Сейчас же у нас имеется протестированный архив, следовательно один из шагов создания образа уже выполнен средствами Jenkins. Мы назовем этот новый файл Dockerfile-packaged.

Докер-файл для микросервиса шлюза аналогичен.

В конце шага происходит удаление установленных локально образов.

Обновление кластера Kubernetes

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

Итоговый Jenkinsfile

Jenkinsfile для микросервиса шлюза полностью аналогичен.

Подключение пайплайна

В Jenkins существует несколько видов пайплайнов. В данном проекте мы используем Multibranch pipeline. Как и следует из названия, билд будет запускаться для любого коммита в произвольной ветке.

Branch sources. Выбираем GitHub, в графе ‘Credentials’ выбираем секрет с логином/паролем от аккаунта и указываем URL репозитория с исходным кодом микросервиса.

Build Configuration. В Mode выбираем ‘by Remote File Plugin’, основное поле — Repository URL, в котором надо указать адрес репозитория с Jenkinsfile, а также Script Path с путем к этому файлу.

Scan Repository Triggers. В этом разделе настроим период, с которым Jenkins будет проверять, появились ли какие-то изменения в отслеживаемом репозитории. Недостаток этого подхода в том, что Jenkins будет генерировать трафик, даже когда в репозитории ничего не менялось. Более грамотный подход — настроить веб-хуки. При этом хранилище исходного кода само будет инициировать запуск билда. Очевидно, что сделать это можно, только если Jenkins доступен по сети для хранилища исходных кодов (они должны быть либо в одной сети, либо Jenkins должен иметь публичный IP-адрес). Подключение веб-хуков оставим за рамками данной статьи.

Запуск

После того как наш пайплайн настроен, можно его запустить. Наиболее удобно это сделать из меню Blue Ocean (Open Blue Ocean). Первый запуск может занять продолжительное время, так как потребуется время на загрузку Maven-зависимостей. После выполнения билда можно подключиться к кластеру и убедиться в том, что тег образа микросервиса был изменен ( helm get values msvc-project ).

В дальнейшем Jenkins будет отслеживать изменения в репозитории микросервиса и запускать билд автоматически.

Заключение

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

Источник