Архив метки: Software

Требования к программному обеспечению для отслеживания времени на 2022 год

Если вы здесь, это означает, что вы ищете лучшее программное обеспечение для отслеживания времени, которое вы будете использовать самостоятельно или вместе со своей командой. Но даже выбрать несколько, чтобы попробовать, может быть запутанной и сложной задачей, поскольку доступно более 100 приложений.

 

Почему важно отслеживать время

Если вы еще не уверены в полезности отслеживания времени, обратите внимание на следующие преимущества:

  • Определите несущественные задачи: у вас нет необходимого времени, чтобы тратить его просто на какую-либо деятельность. Отслеживание времени может помочь вам заменить неважные задачи продуктивными. Вы можете экспортировать эти данные в отчеты и расписания, чтобы использовать их для своих следующих проектов, чтобы не тратить время впустую. Это еще одна причина, по которой вам следует сочетать решения для отслеживания времени с управлением задачами. Еще лучше, если эти две функции являются частью одного и того же собственного приложения, чтобы избежать беспорядка данных.
  • Улучшите оценку времени: вы можете использовать записи времени, отслеживаемые с помощью p, в качестве основного показателя для ваших будущих проектов. С их помощью вы сможете лучше оценить выполнение следующих задач и установить более точные сроки для аналогичных проектов. Отслеживание их эволюции во времени может помочь вам выяснить, успеет ли работник выполнить задачу на основе своей прошлой деятельности. Кроме того, недостаточно обеспеченные сотрудники могут взять на себя ответственность за работу других для достижения более быстрых результатов, если у них есть необходимые навыки.
  • Получайте справедливую оплату: Если вы являетесь фрилансером с почасовой оплатой, простая программа учета рабочего времени поможет вам получить ту сумму денег, которую вы заслуживаете. Это может устранить предположения и неловкие разговоры с проблемными клиентами, которые не желают сотрудничать или не решаются принять решение о ставке оплаты. У вас будут доказательства вашей работы, надежно хранящиеся в Интернете и измеряемые секунду за секундой со всеми вашими журналами учета рабочего времени.

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

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

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

 

Ключевые критерии для выбора лучшего программного обеспечения для отслеживания времени

Вот семь ключевых факторов, которые мы приняли во внимание при рассмотрении этого программного обеспечения для отслеживания времени проекта в этом руководстве:

  • Основные характеристики: Самые важные вещи, которые должны повлиять на ваше решение, — это основные функции программного обеспечения для отслеживания времени. Управление задачами и отчеты необходимы. Такие функции, как автоматическое отслеживание времени или выставление счетов, повышают ценность и могут сделать разницу между отличным приложением и тем, которое будет выполнять эту работу в данный момент. Кроме того, команды могут использовать планирование ресурсов наряду с отслеживанием времени, но эта функция бесполезна для отдельных лиц. Прежде чем выбрать конечный продукт, поговорите со своей командой и выясните, каковы их собственные потребности помимо требований вашего проекта.

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

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

  • Поддержка: Возможно, в какой-то момент вам придется прибегнуть к поддержке клиентов, независимо от того, насколько подготовлена ваша команда, когда дело доходит до технических навыков. Поддержка продукта должна быть легкодоступной, чтобы вы могли быстро получить помощь. Изучите доступные языки, чтобы избежать любых проблем с недопониманием. Однако обратите внимание – степень предлагаемой поддержки может зависеть от уровня вашей подписки. Для некоторых приложений общение с менеджером учетной записи может быть доступно только с тарифными планами премиум-класса, поэтому подумайте, сколько денег вы готовы потратить.

  • Отзывы: Несмотря на то, что каждый инструмент работает по-разному для каждого бизнеса, вы можете взглянуть на то, что говорят существующие пользователи. Capterra и G2-две надежные платформы для проверки пользователей, которые направлены на обеспечение объективной обратной связи с пользователями. Эти обзоры служат основным ориентиром для аспектов, которые вы должны проанализировать и проверить самостоятельно, прежде чем решить, подходит ли программное обеспечение для отслеживания времени для вашего бизнеса.

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

  • Дополнительные функции: Подумайте о любой другой функции, которая вам может понадобиться, от GPS-отслеживания и интеграции до системы утверждения расписания, функции расчета заработной платы или даже чистого или красочного дизайна, чтобы ваша команда была занята.

СОВЕТ: Возьмите эти семь факторов и оцените их в соответствии с вашими потребностями. Сначала создайте электронную таблицу. Затем запишите свои обязательные функции (дайте 5 баллов за каждую), полезные функции (по 2 балла за каждую) и бонусные функции (по 1 баллу за каждую). Добавьте все это, чтобы создать свой собственный рейтинг лучшего программного обеспечения для отслеживания времени, и составьте свой собственный топ для тестирования, прежде чем выбрать одно из них.



2022-01-21T14:47:31
Программное обеспечение

Исправляем статус одиночного сервера ElasticSearch

Зелёный статус для одиночного ElasticSearch




  • Когда мы собеседуем системных администраторов и видим в их резюме упоминание ElasticSearch, мы обязательно задаём им вопрос «какого цвета будет одиночный сервер?»
  • Примерно половина соискателей не понимает его смысла и на этом наше знакомство с ними, как правило, заканчивается (потому что их владение остальными указанными в резюме терминами обычно находится на аналогичном уровне).




Оставшейся половине мы задаём два вопроса:




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




Цвет означает состояние сервера:




  • Зелёный — всё хорошо.
  • Жёлтый — сервер правильно обрабатывает все запросы на чтение/запись, но есть внутренние проблемы, которые необходимо исправить.
  • Красный — всё плохо.




Как увидеть цвет сервера?




  • Запрос:




curl '127.0.0.1:9200/_cluster/health?pretty=true'




  • Пример ответа:




{
  "cluster_name" : "elasticsearch",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 1880,
  "active_shards" : 1880,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 1680,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 52.80898876404494
}




Почему отдельный сервер будет по умолчанию жёлтым?




  • Потому что ElasticSearch является отказоустойчивой системой хранения данных, которая расчитана для запуска не на одном сервере, а на группе (кластере) из нескольких связанных серверов (узлов, “nodes”).
  • В частности, ElasticSearch подразумевает, что при отказе одного узла система должна сохранять полную работоспособность.
  • Для этого система должна состоять из нескольких серверов (минимум — двух, желательно — трёх для предотвращения split brain), и каждая порция данных (т.н. “shard” в терминологии ES) должна храниться в нескольких экземплярах на разных серверах.
  • Один из этих экземпляров ES будет считать первичным (“master shard”), остальные копиями первичного (“replica shards”).
  • В системе из одного сервера ES хранит на нём все “primary shards”, но создавать “replica shards” такой системе будет негде.
  • Поэтому статус в приведённом примере является жёлтым из-за ненулевого значения “unassigned_shards”, которое примерно равно “active_shards”.
  • Небольшая разница между количеством активных и неразмещённых шардов обусловлена тем, что часть служебных индексов является локальной для каждого узла, то есть не должна иметь реплик и не приводит к появлению unassigned shards.
  • Подробнее о том, что такое шарды, зачем они нужны, и какое место занимают между документами и индексами: https://stackoverflow.com/a/49892584/2743554.




Как сделать одиночный сервер зелёным?




  • Сначала узнаем, какие шарды система не сумела разместить:




curl -sS -XGET '127.0.0.1:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason' | grep UNASSIGNED




  • Теперь посмотрим, к каким индексам они относятся:




curl -sS -XGET '127.0.0.1:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason' | awk '/UNASSIGNED/ { print $1 }'




  • После этого поменяем настройки индексов — уменьшим количество реплик (так называемый Replication Factor) до нуля:




curl -sS -XGET '127.0.0.1:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason' | awk '/UNASSIGNED/ { print $1 }' |
while read idx; do
    curl -XPUT "localhost:9200/$idx/_settings" -H 'Content-Type: application/json' -d '{ "index": { "number_of_replicas": 0 } }'
done




или




curl -sS -XGET '10.233.108.217:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason' | awk '/UNASSIGNED/ { print $1 }' 




  • И проверим результат:




{
  "cluster_name" : "elasticsearch",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 1880,
  "active_shards" : 1880,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}




Почему в полночь карета превратится в тыкву сервер снова станет жёлтым?




  • Потому что в ES принято каждые сутки автоматически создавать новый индекс с именем вида “basename-yyyy.mm.dd” из шаблона.
  • Поэтому Replication Factor необходимо уменьшить до нуля не только в существующих индексах, но и в шаблонах, из которых будут создаваться новые индексы.
  • Это делается так:




curl -XPUT "127.0.0.1:9200/_template/all?pretty=true" -H 'Content-Type: application/json' -d 
'{ "template" : "*" , "settings": { "number_of_replicas": 0 } }' 




или




curl -XPUT "10.233.108.217:9200/$idx/_settings" -H 'Content-Type: application/json' -d '{ "index": { "number_of_replicas": 0 } }'




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




Источник: https://cdnnow.ru/blog/esgreen/



2022-01-13T01:38:45
Software

Техническая документация. Что это такое

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

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

Техническая документация создается с единственной целью упростить конечному пользователю понимание динамики работы и архитектуры продукта или технологии, которые они используют. Это больше похоже на подробное описание гаек и болтов продукта – руководство “как пользоваться” для ваших новых сотрудников, пользователей и всех, кому нужно знать, как это работает!

Однако, как бы просто это ни звучало, техническая документация может быть немного сбивающей с толку! Большинство технических документов включают в себя несколько этапов, начиная с “Как использовать: Если вы новичок и имеете ограниченный опыт”, “ Неотредактированное резюме: Обо всем, что разработчик предоставляет через API” до “Как устранить неполадки: В случае ошибки или ошибки!”

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

Давайте окапываться!

 

Что такое Техническая документация?

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

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

Группа компаний ТехСерт https://tech-sert.ru/tehdoc, имеет аккредитацию и многолетний опыт работы, в рамках которых мы оказываем услуги по оформлению Европейского сертификата качества.

 

 

Где и Как Вы можете использовать Различные Виды Технической документации?

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

  • Поддержка конечных пользователей: Это означает такие документы, как руководства пользователя, онлайновые справочные системы, примечания к выпуску, учебные пособия, руководства по установке или операционные процедуры-все, что поддерживает пользователей вашего продукта.
  • Маркетинговая поддержка: Документы, ориентированные на продукт и используемые для продвижения вашей компании, такие как компьютерные обучающие видеоролики, презентации, онлайн-справка или технические целевые страницы.
  • Поддержка разработки: Это может включать технические и функциональные спецификации, руководства по разработке программных продуктов, глоссарии или простые процедуры и инструменты, помогающие вашим техническим командам выполнять свою работу.
  • Организационная поддержка: Информация о вашей компании, структуре, процедурах, кратких справочных руководствах, рабочих процессах, политиках, руководствах по техническому обслуживанию и обо всем, что сотрудникам необходимо знать для выполнения своей работы.

 

Преимущества Технической Документации Для Вашего Бизнеса

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

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

Кроме того, четко определенная техническая документация также помогает в:

 

1. Техническая Документация Улучшает Удержание Клиентов

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

Недавнее исследование SDL по технической документации показывает растущее значение документации на мировых рынках-

  • 53% клиентов, как правило, используют техническую документацию, чтобы понять продукт перед совершением покупки.
  • 94% клиентов считают, что важно и полезно иметь информацию о продукте в одном месте.

Следовательно, в настоящее время каждая компания в равной степени уделяет внимание документации наряду с разработкой или тестированием продукта!

 

2. Хорошая техническая документация Экономит время и усилия

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

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

 

3. Техническая Документация может Повысить Ваши Продажи

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

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



2021-12-14T09:47:06
Программное обеспечение

Настройка репликации PostgreSQL в контейнерах Docker

Мы рассмотрим процесс поднятия двух контейнеров с PostgreSQL и настройки репликации данных между ними. Использовать будем систему на базе Linux, однако, сам процесс настройки Docker и репликации не зависит от операционной системы.




Подготовка компьютера




На компьютере, где мы будем запускать наш кластер баз данных должен быть установлен Docker. Также мы сразу рассмотрим развертывание нужной нам инфраструктуры в docker-compose. Для установки необходимой одноименной платформы смотрим инструкцию Установка Docker на Linux.




После мы можем переходить к поднятию контейнеров.




Запуск контейнеров с СУБД




Как говорилось выше, мы будем поднимать наши контейнеры с помощью docker-compose.




Создадим каталог, в котором будем работать:




mkdir -p /opt/docker/postgresql




Переходим в него:




cd /opt/docker/postgresql




Создаем файл для docker-compose:




vi docker-compose.yml




---



services:



  postgresql_01:

    image: postgres

    container_name: postgresql_01

    restart: always

    volumes:

      - /data/postgresql_01:/var/lib/postgresql/data

    environment:

      POSTGRES_PASSWORD: postgres024



  postgresql_02:

    image: postgres

    container_name: postgresql_02

    restart: always

    volumes:

      - /data/postgresql_02/:/var/lib/postgresql/data

    environment:

      POSTGRES_PASSWORD: postgres024




* рассмотрим некоторый опции подробнее:







Запускаем наши контейнеры:




docker-compose up -d




Мы должны увидеть:




Creating postgresql_02 ... done

Creating postgresql_01 ... done




А если вывести список контейнеров:




docker ps




… мы должны увидеть наши два.




Теперь можно переходить к настройке репликации.




Настройка репликации




Условимся, что первичный сервер или master будет в контейнере с названием postgresql_01. Вторичный — postgresql_02. Мы будем настраивать потоковую (streaming) асинхронную репликацию.




Настройка на мастере




Подключаемся к контейнеру docker:




docker exec -it postgresql_01 bash




Заходим под пользователем postgres:




su - postgres




Создаем пользователя, под которым будем подключаться со стороны вторичного сервера:




createuser --replication -P repluser




* в данном примере будет создаваться учетная запись repluser с правами репликации.




Система потребует ввода пароля. Придумываем его и набираем дважды.




Выходим из-под пользователя postgres:




exit




Выходим из контейнера:




exit




Открываем конфигурационный файл postgresql.conf:




vi /data/postgresql_01/postgresql.conf




Приводим к следующием виду некоторые параметры:




wal_level = replica

max_wal_senders = 2

max_replication_slots = 2

hot_standby = on

hot_standby_feedback = on




* где







Посмотрим подсеть, которая используется для контейнеров с postgresql:




docker network inspect postgresql_default | grep Subnet




В моем случае, ответ был:




"Subnet": "172.19.0.0/16",




Теперь открываем файл:




vi /data/postgresql_01/pg_hba.conf




И добавляем строку после остальных «host    replication»:




host    replication     all             172.19.0.0/16           md5




* в данном примере мы разрешили подключение пользователю replication из подсети 172.19.0.0/16 с проверкой подлинности по паролю.




Перезапустим докер контейнер:




docker restart postgresql_01




Настройка на слейве




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




rm -r /data/postgresql_02/*




* в данном примере мы удалим все содержимое каталога /data/postgresql_02.




Мы должны быть уверены, что в базе нет ничего важного. Только после этого стоить удалять данные.




Заходим внутрь контейнера postgresql_02:




docker exec -it postgresql_02 bash




Выполняем команду:




su - postgres -c "pg_basebackup --host=postgresql_01 --username=repluser --pgdata=/var/lib/postgresql/data --wal-method=stream --write-recovery-conf"




* где postgresql_01 — наш мастер; /var/lib/postgresql/data — путь до каталога с данными слейва.




Система должна запросить пароль для пользователя repluser — вводим его. Начнется процесс репликации, продолжительность которого зависит от объема данных.




Проверка




Смотрим статус работы мастера:




docker exec -it postgresql_01 su - postgres -c "psql -c 'select * from pg_stat_replication;'"




Смотрим статус работы слейва:




docker exec -it postgresql_02 su - postgres -c "psql -c 'select * from pg_stat_wal_receiver;'"




Источник: https://www.dmosk.ru/miniinstruktions.php?mini=postgresql-replication-docker



Ansible: Сбор произвольной информации на хостах с помощью Ansible custom facts. Вывод информации в формате *.json.

На чем было опробовано:




  1. Ansible 2.9.18
  2. Hyper-V на Windows 10 Pro.
  3. Сервер Ansible: CentOS Linux release 7.9.2009 (Core).
  4. Node 1: CentOS Linux release 7.9.2009 (Core).
  5. Node 2: CentOS Linux release 7.9.2009 (Core).
  6. Node 3: CentOS Linux release 7.9.2009 (Core).
  7. Node 4: CentOS Linux release 7.9.2009 (Core).








1. Задача.




К примеру, нам требуется с помощью внедрения custom facts для Ansible организовать сбор версий контейнеров, запущенных на серверах, а так же сбор версий некоторого программного обеспечения на серверах, которое имеет файл с указанием версии в своём каталоге /ecp/po/version.txt.




Собранная информация должна формироваться в json-формат.




Дополнительно требуется рассмотреть средства визуализации информации в удобном виде (opensource web-приложения).




2. Решение задачи.




Решение будет состоять из нескольких этапов:







В системе Ansible есть возможность собирать системную информацию, которая собирается в виде фактов с помощью встроенного модуля setup.




Со сбором стандартных переменных по умолчанию всё предельно ясно, но что делать, если мы хотим сформировать наши собственные переменные на всех хостах, чтобы в дальнейшем использовать их в нашем коде?




Для этого существует возможность добавления Custom facts, что делается следующим образом:







Создаем инвентарь test-servers.inventory на 4 тестовых сервера:




# mcedit /ansible/test-servers.inventory




С таким содержимым:




[test_servers]
server1   ansible_ssh_host=192.168.0.39 ansible_ssh_user=root
server2   ansible_ssh_host=192.168.0.30 ansible_ssh_user=root
server3   ansible_ssh_host=192.168.0.31 ansible_ssh_user=root
emachines ansible_ssh_host=192.168.0.12 ansible_ssh_user=root




Создаем специальный custom.fact файл для загрузки на узлы, который, по сути, является скриптом для выполнения некоторого комплекса действий на удалённом узле.




По замыслу будут собираться некоторые переменные и заворачиваться в разметку json.




#!/bin/bash

file_po="/etc/po/version.txt"
host_name=$(hostname)
ecp_ver=$(awk -F: '/rel_ver/{print $2}' $file_po)
docker_info=$(docker ps --format ' {{json .Names}}: {{json .Image}}, ' | paste -sd'n' | sed '$ s/.$//')
jp="/$host_name.json"

echo "{" > $jp
echo ""Информация об узлах": {" >> $jp
echo ""$host_name": {" >> $jp
if test -f "$file_po"; then
    echo ""Софт": {" >> $jp
    echo ""Версия чего-то": "$ecp_ver"" >> $jp
    echo "}" >> $jp
    echo "," >> $jp
fi
echo ""Докеры на узле": {" >> $jp
echo "$docker_info" >> $jp
echo "}" >> $jp
echo "}" >> $jp
echo "}" >> $jp
echo "}" >> $jp




Создаём специальный playbook custom-facts-fetch.yml, содержащий сценарий /ansible/files/custom.fact для узла, возвращающий некоторый файл json на Ansible master сервер с каждого узла:




---
- name: "Cбор Ansible custom facts"
  hosts: all

  tasks:
  - name: "Удаление предыдущей версии Ansible custom facts файлов на узле"
    file:
      state: "absent"
      path: "/etc/ansible/facts.d/"

  - name: "Создание Ansible custom fact каталога"
    file:
      path: "/etc/ansible/facts.d"
      state: "directory"
      mode: 0766

  - name: "Загрузка на узлы Ansible custom fact файлов"
    copy:
      src: "/ansible/files/custom.fact"
      dest: "/etc/ansible/facts.d/custom.fact"
      mode: +x

  - name: "Объявление служебной переменной для Ansible custom fact"
    debug: "var=ansible_local"
    notify:
    - reload facts

  - name: "Перезагрузка facts"
    setup: "filter=ansible_local"

  - name: "Подготовка списка файлов *.json для выгрузки с узла"
    find:
      paths: "/"
      recurse: "no"
      patterns: "*.json"
    register: "files_to_copy"

  - name: "Выгрузка файлов *.json с узла на Ansible master сервер"
    fetch:
      src: "{{ item.path }}"
      dest: "/ansible/json"
    with_items: "{{ files_to_copy.files }}"




Напишем скрипт custom-facts-fetch-PLAY.sh для запуска playbook на целевом inventory:




#!/bin/bash.

ansible-playbook /ansible/custom-facts-fetch.yml -i /ansible/test-servers.inventory




Сделаем файл скрипта исполняемым:




# chmod +x custom-facts-fetch-PLAY.sh




И запустим его.




Ответ:







После успешной отработки playbook на сервере Ansible master появится каталог /ansible/json с подкаталогами ‘имя_узла‘:







В каждом из которых будет находиться json файл вида имя_узла.json:
















Содержимое json файла первого узла emachines:







Содержимое json файла второго узла server1:







Содержимое json файла третьего узла server2:







Содержимое json файла четвертого узла server3:







Получилось несколько файлов json, по файлу с каждого целевого узла.




Сколько узлов мы задействовали для Ansible custom facts, столько и json файлов и будет.




В первом файле emachines.hamsterden.loc.json не имеется фрагмент с названием «Версия чего-то‘, по втором файле cos7client1.hamsterden.loc.json такой фрагмент имеется, а так как в custom.fact реализована проверка на фактическое наличия файла /ecp/po/version.txt.




К примеру, наличие файла /ecp/po/version.txt бывает только у серверов типа «web-server». Так как скрипт «сам учитывает» тип сервера, то можно смело применять custom.fact на все целевые серверы и файл json всегда будет генерироваться корректно для каждого типа серверов.




Для создание сводного json файла по всем файлам со всех узлам, воспользуемся утилитой jq.




Ссылка на официальный сайт утилиты: https://stedolan.github.io/jq/.




Установка утилиты:




# yum install jq -y




План работ с файлами:




file1.json + file3.json + file3.json + file4.json = final_result_po.json




Создадим make-final-json-file.sh скрипт:




# mcedit /ansible/make-final-json-file.sh




#!/bin/bash

#создание каталогов для обработки файлов
mkdir -p /ansible/json/temp
mkdir -p /ansible/json-ready

#каталог куда Ansible кладет скачанные json файлы с узлов
ja="/ansible/json"

#временный каталог куда Ansible складывает все json файлы из всех каталогов узлов перед сведением информации в единый файл json
jrt="/ansible/json/temp"

#каталог куда Ansible помещает сводный json файл со всей добытой информацией по узлам
jr="/ansible/json-ready"

#обработка файлов и удаление временных промежуточных результатов
cp -i $(find /$ja -iname "*.json") $jrt
cd $jrt
jq -s '.[0] * .[1] * .[2] * .[3]' *.json > "$jrt"/temp.json
cat "$jrt"/temp.json | sed 's/{}/"нет докеров"/' > "$jr"/final_result_po.json

#удаление временных каталогов и файлов
rm -rf $jrt
rm -rf $ja




Сделаем файл скрипта исполняемым:




# chmod +x /ansible/make-final-json-file.sh




Результатом работы скрипта будет сводный json файл всех четырёх final_result_po.json в каталоге /ansible/json_ready на Ansible master сервере:







Текстовый файл:




{
  "Информация об узлах": {
    "cos7client1.hamsterden.loc": {
      "Софт": {
        "Версия чего-то": "9.11.2"
      },
      "Докеры на узле": {
        "wordpress-compose_nginx_1": "nginx:latest",
        "wordpress-compose_wordpress_1": "wordpress:php7.4-fpm-alpine",
        "wordpress-compose_pma_1": "phpmyadmin/phpmyadmin",
        "wordpress-compose_mysql_1": "mariadb"
      }
    },
    "cos7client2.hamsterden.loc": {
      "Софт": {
        "Версия чего-то": "10.2.1"
      },
      "Докеры на узле": "нет докеров"
    },
    "cos7client3.hamsterden.loc": {
      "Софт": {
        "Версия чего-то": "9.3.4"
      },
      "Докеры на узле": "нет докеров"
    },
    "emachines.hamsterden.loc": {
      "Докеры на узле": {
        "onlyoffice": "onlyoffice/documentserver",
        "funny_heisenberg": "onlyoffice/documentserver"
      }
    }
  }
}




Если открыть final_result_po.json файл в браузере Mozilla Firefox, то информация будет корректно визуализирована в удобно читаемом виде:







Задача выполнена!




X. Оригиналы источников информации.




  1. golinuxcloud.com «Working with Ansible facts | Create custom facts with examples».
  2. github.com «Ansible local fact example».
  3. medium.com «Custom facts for Ansible».
  4. otus.ru «Ansible: формируем переменные на всех хостах с Custom facts».
  5. mydailytutorials.com «Working with Ansible facts – retrieving facts».
  6. adyxax.org «Ansible custom factsAnsible custom facts».
  7. Источник: https://hamsterden.ru/ansible-collecting-arbitrary-information-on-all-hosts-with-custom-facts/






2021-09-01T15:48:22
Software

Ansible: Часть 5. Настройка защищенных плейбуков.

На чем было опробовано:




  1. Ansible 2.9.18
  2. Hyper-V на Windows 10 Pro.
  3. Сервер Ansible: CentOS Linux release 7.9.2009 (Core).
  4. Node 1: CentOS Linux release 7.9.2009 (Core).
  5. Node 2: CentOS Linux release 7.9.2009 (Core).
  6. Node 3: CentOS Linux release 7.9.2009 (Core).








1. Введение.




Как установить и первоначально настроить Ansible описано здесь:




Ссылка: «Ansible: Часть 1. Описание, установка и первоначальная настройка.»




Так как простые задачи для Ansible реально простые, в буквальном смысле слова, то я принял решение вынести их в отдельную инструкцию:




Ссылка: «Ansible: Часть 2. Примеры простых задач.»




Рассмотрим структуру и правила написания таких сценариев более подробно.




Ссылка: «Ansible: Часть 3. Сценарии (плейбуки) — Playbooks.»




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




Ссылка: «Ansible: Часть 4. Практические примеры плейбуков.»




2. Ansible Vault для хранения конфиденциальных данных.




Если ваши плейбуки Ansible содержат конфиденциальные данные, такие как пароли, ключи API и учетные данные, важно обеспечить их безопасность с помощью шифрования. Ansible предоставляет ansible-vault для шифрования файлов и переменных.




Несмотря на то, что любой файл данных Ansible, а также двоичные файлы, возможно зашифровать изначально, чаще для шифрования переменных файлов, содержащих конфиденциальные данные, используется ansible-vault. После шифрования файла с помощью этого инструмента вы сможете выполнять, редактировать или просматривать его, только предоставив соответствующий пароль, указанный при первом шифровании файла.




2.1. Создание нового зашифрованного файла.




Вы можете создать новый зашифрованный файл Ansible с помощью:




# ansible-vault create credentials.yml




Эта команда выполнит следующие действия:




  1. Сначала вам будет предложено ввести новый пароль. Вам нужно будет указывать этот пароль при каждом доступе к содержимому файла, будь то редактирование, просмотр или просто запуск плейбука или команд с использованием его значений.
  2. Затем откроется редактор командной строки по умолчанию, чтобы вы могли заполнить файл требуемым содержимым.
  3. Наконец, когда вы закончите редактирование, ansible-vault сохранит файл как зашифрованный.




2.2. Шифрование существующего файла.




Чтобы зашифровать существующий файл Ansible, вы можете использовать следующую команду:




# ansible-vault encrypt credentials.yml




Эта команда запросит у вас пароль, который вам нужно будет вводить при каждом доступе к файлу credentials.yml.




2.3. Просмотр содержимого зашифрованного файла.




Если вы хотите просмотреть содержимое файла, который ранее был зашифрован с помощью ansible-vault, и вам не нужно изменять его содержимое, вы можете использовать команду:




# ansible-vault view credentials.yml




Она предложит вам указать пароль, который вы выбрали при первом шифровании файла с помощью ansible-vault.




2.4. Редактирование зашифрованного файла.




Чтобы изменить содержимое файла, который ранее был зашифрован с помощью ansible-vault, выполните:




# ansible-vault edit credentials.yml




Эта команда предложит вам указать пароль, который вы выбрали при первом шифровании файла credentials.yml. После проверки пароля откроется редактор командной строки по умолчанию с незашифрованным содержимым файла, что позволит вам внести нужные изменения. По завершении вы можете сохранить и закрыть файл, как обычно, и обновленное содержимое будет сохранено и зашифровано.




2.5. Расшифровка файлов.




Если вы хотите навсегда расшифровать файл, ранее зашифрованный с помощью ansible-vault, вы можете сделать это с помощью следующего синтаксиса:




# ansible-vault decrypt credentials.yml




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




3. Использование нескольких паролей.




Ansible поддерживает для хранилища несколько паролей, сгруппированных по разным идентификаторам. Это полезно, если вы хотите иметь выделенные пароли хранилища для различных сред – для разработки, тестирования и производства.




Чтобы создать новый зашифрованный файл с пользовательским идентификатором хранилища, включите параметр --vault-id вместе с меткой и расположением, где ansible-vault может найти пароль для этого хранилища. Метка может быть любой, а расположение может быть либо prompt (что означает, что команда должна предложить вам ввести пароль), либо путь к файлу паролей.




# ansible-vault create --vault-id dev@prompt credentials_dev.yml




Это создаст новый идентификатор по имени dev, который использует prompt для получения пароля. Комбинируя этот метод с файлами переменных группы, вы сможете создать отдельные хранилища для каждой среды приложения:




# ansible-vault create --vault-id prod@prompt credentials_prod.yml




Мы использовали dev и prod в качестве идентификаторов хранилищ, чтобы продемонстрировать, как вы можете создавать отдельные хранилища для каждой среды. Самостоятельно вы можете создать столько хранилищ, сколько захотите, и использовать любой ID.




Теперь, чтобы просмотреть, отредактировать или расшифровать эти файлы, вам необходимо предоставить тот же ID хранилища и источник пароля вместе с командой ansible-vault:




# ansible-vault edit credentials_dev.yml --vault-id dev@prompt




4. Использование файла паролей.




Если вам нужно автоматизировать процесс инициализации серверов в Ansible с помощью стороннего инструмента, вам потребуется способ ввода пароля хранилища без его запроса. Вы можете сделать это, используя файл паролей через ansible-vault.




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




Чтобы применить файл паролей в ansible-vault, необходимо указать путь к файлу паролей при выполнении любой из команд vault:




# ansible-vault create --vault-id dev@path/to/passfile credentials_dev.yml




Ansible не различает контент, который был зашифрован с помощью prompt, и простой файл пароля при условии, что входной пароль один и тот же. С практической точки зрения это означает, что файл можно зашифровать, используя prompt, а затем создать файл пароля для хранения того же пароля, который использовался в методе prompt. Также верно и обратное: вы можете зашифровать содержимое, используя файл паролей, а затем использовать метод prompt, предоставляя тот же пароль при запросе Ansible.




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




Официальный репозиторий Ansible содержит несколько примеров сценариев, которые вы можете использовать для справки при создании своего скрипта под потребности вашего проекта.




5. Запуск плейбука с зашифрованными данными.




Каждый раз, когда вы запускаете плейбук, в котором используются данные, ранее зашифрованные с помощью ansible-vault, вам нужно будет указывать пароль хранилища в команде playbook.




Если вы использовали параметры по умолчанию и prompt при шифровании данных плейбука, вы можете использовать опцию --ask-vault-pass, чтобы Ansible запрашивал пароль:




# ansible-playbook myplaybook.yml --ask-vault-pass




Если вы использовали файл пароля вместо prompt, вы должны использовать опцию --vault-password-file:




# ansible-playbook myplaybook.yml --vault-password-file my_vault_password.py




Если вы используете данные, зашифрованные с помощью ID, вам нужно указать тот же ID хранилища и источник пароля, который вы использовали при первом шифровании данных:




# ansible-playbook myplaybook.yml --vault-id dev@prompt




Если вы используете файл пароля с ID, вы должны указать метку, а затем полный путь к файлу пароля в качестве источника:




# ansible-playbook myplaybook.yml --vault-id dev@vault_password.py




Если ваш play использует несколько хранилищ, вы должны добавить параметр --vault-id для каждого из них в произвольном порядке:




# ansible-playbook myplaybook.yml --vault-id dev@vault_password.py --vault-id test@prompt --vault-id ci@prompt




6. Оригиналы источников информации.




  1. selectel.ru «Система управления конфигурацией Ansible».
  2. dmosk.ru «Инструкция по установке и запуску Ansible на CentOS».
  3. dmosk.ru «Что такое ansible».
  4. 8host.com «Как работать с Ansible: простая удобная шпаргалка».
  5. habr.com «Автоматизируем и ускоряем процесс настройки облачных серверов с Ansible. Часть 1: Введение».
  6. kamaok.org.ua «Установка и использование Ansible на Centos7».
  7. Источник: https://hamsterden.ru/ansible-vault-playbooks/






2021-09-01T15:40:11
Software