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

^{Фото ZACHARY STAINES / Unsplash}

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

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

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

^{Фото Keith Tan / Unsplash}

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

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

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

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

^{Фото Larry George II / Unsplash}

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

Как психика реагирует на аудиотриггеры. Разбираемся, почему одни звуки вовлекают нас в танец, а другие заставляют съёживаться и закрывать уши. Рассказываем про гиперчувствительность и обсуждаем, как формируется восприятие, и почему оно может приводить к ощутимым различиям: кто-то даже не заметит, как гудит автобус, но другие будут раздражены от постоянного шума.

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

Дополнительное чтение:

• От советских автомагнитол до вилки с шумоподавлением
• Реплики звуковых карт, открытые библиотеки звуков и аудиософт
• Музыкальные дороги, HD-пластинки и 8D-звук

Предисловие

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

Список статей

1. Как я писал полудецентрализованную криптовалюту на PHP. (Часть 1 — Сбор библиотек)
2. Как я писал полудецентрализованную криптовалюту на PHP. (Часть 2 — Разработка)

Поговорим о библиотеке BPN

Сам я, если честно, не видал P2P библиотек под PHP, и эта библиотека была единственным выбором.
Библиотека поддерживает полу-децентрализованный P2P, соответственно, там поддерживаются трекеры.
В BPN поддерживаются два типа трекера: Native-трекер и Web-трекер.
Native-трекер, как правило можно запустить на каком нибудь другом компьютере (из одной библиотеки).
Web-трекер предназначен только для установки на сайт, поскольку в нем нету функции клиента.

Установка трекера

Переходим на репозиторий GitHub, о котором я говорил в предыдущей части. Master-ветка нас не интересует, выбираем web. Скачиваем архив с этой веткой, распаковываем его и открываем в блокноте или где нибудь еще, где Вам удобнее, файл index.php. Вот контент файла:

<?php  /**  * This program is free software: you can redistribute it and/or modify  * it under the terms of the GNU General Public License as published by  * the Free Software Foundation, either version 3 of the License, or  * (at your option) any later version.  *   * @package     Bit Points Network  * @copyright   2020 Podvirnyy Nikita (Observer KRypt0n_)  * @license     GNU GPLv3 <https://www.gnu.org/licenses/gpl-3.0.html>  * @author      Podvirnyy Nikita (Observer KRypt0n_)  *   * Contacts:  *  * Email: <suimin.tu.mu.ga.mi@gmail.com>  * VK:    <https://vk.com/technomindlp>  *        <https://vk.com/hphp_convertation>  *   */  namespace BPN;  const TRACKER_KEY = 'EFJI#*$&(*#WEF(@Q#)(DFJSAO(@#*$)REFSKE)UJ*#@(&$';  require 'ext/DH-Generator/Generator.php'; require 'php/User.php'; require 'php/Tracker.php';  $tracker = new Tracker; $tracker->update ();  if (isset ($_GET['r']))     $tracker->processRequest ($_GET['r']);

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

 const TRACKER_KEY = 'sdT*&Y&*YO*&T*OGTGYFIYYUFGKUHLIYIj9sfhysdphphdpsfhBLABLABLAhsidlfhlisd'; 

Это всего лишь пример. Вы должны изменить по своему. Выкладываем все это на хостинг. Настройка веб-трекера завершена.
Native-трекер ставить не будем. Хотя если у Вас провайдер с белым IP и возможностью открывать порты — пожалуйста. Правда оставьте компьютер 24/7.

Разработка

General

Итак, нам нужно создать ядро, через которое будет осуществляться вызов всех функций, включая консоль.
Создаем файл General.php. Вставляем туда следующий код:

<?php  declare (strict_types=1);  require_once __DIR__ . '/vendor/autoload.php'; # Подключение компоузерских пакетов  require_once 'PHP/Structure.php';              # Структура require_once 'PHP/UserAPI.php';                # Аккаунт  require_once 'NotComposer/vendor/autoload.php';# Подключение не-компоузерных пакетов  require_once 'PHP/App.php';                    # Консолька

Библиотека для BIP39 требует строгую типизацию, обьявляем его в первых строчках кода.
Сами библиотеки BIP39 и BIP44 подгружаем файлом autoload.php, стандартным для Composer.
Структуру данных обьявим в Structure.php.
Функции для работы с кошельками будут в файле UserAPI.php.
Библиотеки BPN и phpblockchain не совместимы с Composer, создаем файл, по названию похожий с Composer.
Само приложение выносим в App.php — оно будет там последним подключенным файлом, поскольку надо сначала все сверху прогрузить.

NotComposer/vendor/autoload.php

В этом файле я подключаю все несовместимые с Composer библиотеки.
Он похож на General.php, за исключением того что тут подключаются библиотеки, а не модули в целом.

Structure

Здесь собраны структуры данных. Некоторые из них пригодятся UserAPI.php и App.php.
Код:

<?php  class Account { 	public $address; 	public $publicKey; 	protected $privateKey;  	public function getPrivateKey () 	{ 		return $this->privateKey; 	}  	public function setPrivateKey ($key) 	{ 		$this->privateKey = $key; 	} }  class AccountChain { 	public $accounts; }

Примитивный код, не так ли?

UserAPI.php

Посредник между Structure.php и App.php является UserAPI.php. Именно он предназначен для хранения собственных кошельков. Он поддерживает следующие методы:
registerNewAccount (string $password) — Создать аккаунт. Пароль необходим для создания seed.
registerNewAccountInChain (object &$chain, string $password, string $prevAccountMnemonic) — Создать еще один аккаунт. Требует мнемоническую фразу первого аккаунта, чтобы восстановить ключевую пару. Хотя из файла accounts можно взять… Лень.
restoreAccount (string $mnemonic, string $password, int $accountNo) — Восстановить один из аккаунтов мнемонической фразой и паролем.
Код этого файла:

<?php  use \FurqanSiddiqui\BIP39\BIP39; use BIP\BIP44;  class User { 	public $account;  	public function registerNewAccount ($password) 	{ 		$mnemonic = BIP39::Generate (18); 		$seed = $mnemonic->generateSeed ($password, 256);  		$HDKey = BIP44::fromMasterSeed ($seed)->derive ("m/44'/0'/0'/0/1");  		$newAccount = new Account; 		$newAccount->address = '1x' . hash ('ripemd160', hash ('sha512', $HDKey->publicKey)); 		$newAccount->publicKey = $HDKey->publicKey; 		$newAccount->setPrivateKey ($HDKey->privateKey);  		$accountChain = new AccountChain; 		$accountChain->accounts = []; 		$accountChain->accounts[] = $newAccount; 		 		return ['words' => $mnemonic->words, 'chain' => $accountChain]; 	}  	public function registerNewAccountInChain (&$chain, $password, $prevAccountMnemonic) 	{ 		$mnemonic = BIP39::Words ($prevAccountMnemonic); 		$seed = $mnemonic->generateSeed ($password, 256);  		$accountsCount = sizeof ($chain->accounts) + 1;  		$HDKey = BIP44::fromMasterSeed ($seed)->derive ("m/44'/0'/0'/0/{$accountsCount}");  		$newAccount = new Account; 		$newAccount->address = '1x' . hash ('ripemd160', hash ('sha512', $HDKey->publicKey)); 		$newAccount->publicKey = $HDKey->publicKey; 		$newAccount->setPrivateKey ($HDKey->privateKey);  		$chain->accounts[] = $newAccount;  		return ['chain' => $chain]; 	}  	public function restoreAccount ($mnemonic, $password, $accountNo) 	{ 		$mnemonic = BIP39::Words ($mnemonic); 		$seed = $mnemonic->generateSeed ($password, 256);  		$HDKey = BIP44::fromMasterSeed ($seed)->derive ("m/44'/0'/0'/0/{$accountNo}");  		$newAccount = new Account; 		$newAccount->address = '1x' . hash ('ripemd160', hash ('sha512', $HDKey->publicKey)); 		$newAccount->publicKey = $HDKey->publicKey; 		$newAccount->setPrivateKey ($HDKey->privateKey);  		$accountChain = new AccountChain; 		$accountChain->accounts = []; 		$accountChain->accounts[] = $newAccount;  		return $accountChain; 	} }

App

Следующим на очереди один из важных файлов — App.php. Именно он осуществляет все операции в сети.
Код:

Подведем итоги

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

Привет, Хабр! Представляю вашему вниманию перевод статьи "ECS back and forth — Part 1 — Introduction" автора Michele skypjack Caini.

ECS back and forth

Часть 1 — Введение.

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

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

Почему я должен использовать ECS?

Старайтесь не быть одураченным тем, что говорят вокруг. Если вы работаете над AAA проектами на серьёзном уровне, главной причиной почему вы должны использовать такой серьёзный инструмент — это организация кода, а не (только) производительность. Конечно, производительность имеет не последнее значение, но хорошо организованная кодовая база бесценна, и с большинством игр у вас не будет проблем с производительностью, будь они написаны с использованием ОПП парадигмы либо с другой опциональной реализацией компонентного шаблона.

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

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

Введение

Для начала давайте разберёмся в том, что значит перейти с ООП в компонентный мир.

Грубо говоря, это вопрос разделения вещей. Представь все свои концепты(классы) объектов на плоскости. Здесь дварф, эльф, игровой персонаж, камень и так далее, все следуют друг за другом. И вот тут в нас остаётся только два способа разрезать это: горизонтально и вертикально.
Если вы будете резать вертикально, то получите сами концепты по себе. Другими словами, обычные ООП классы, ничего больше, ничего меньше.

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

Но как организовывать логику теперь?

Классическое ООП предлагает вам итерировать все объекты (представителей ваших классов), используя некоторый update метод. Следуя нашему прошлому примеру, мы можем пройтись через все сущности и обновить их, как будто они колонки, работая с одной колонкой за раз.

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

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

ECS back and forth

Рассмотрим несколько известных путей реализации ECS.

В первой части этой серии статей, я опишу возможно менее привлекательный путь, но представляющий первый шаг к полноценному компонентному подходу. Несколько отличающуюся реализацию можно найти в великой книге Роберта Нистрома
«Game Programing Patterns». Вот ссылка на бесплатную веб-версию.

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

Но для начала, давайте погрузимся в детали, которые помогут в дальнейшем её описании.

Уникальные идентификаторы

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

Самым распространённое требование – это наличие уникальных во время выполнения программы идентификаторов компонентов. Позже мы узнаем какие проблемы они решают.

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

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

Распространённый подход решения озвученной проблемы – family generator. Это смесь шаблонов и статических элементов, занимающие несколько строчек кода. Свободное ПО, использующее эту технику: entityx and EnTT.

Возможная реализация family generator.

class family {     static std::size_t identifier() noexcept {         static std::size_t value = 0;         return value++;     }   public:     template<typename>     static std::size_t type() noexcept {         static const std::size_t value = identifier();         return value;     } };

Пример генерации уникального идентификатора для данного типа:

const auto id = family::type<my_type>();

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

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

С начала: ассоциативные массивы и иерархии

Наиболее очевидная реализация компонентно-ориентированной модели включает в себя ассоциативные массивы (вроде того) и ООП объекты. Обычно такой подход – первая попытка разработки самодельной ECS, который, по моему мнению, находится между чистым ООП и полным компонентно-ориентированным подходом.

Проще говоря, объекты всё ещё существуют, но их типы в привычном нам виде каким-то образом замещаются наборами компонентов, содержащиеся в них.

Но как это работает на самом деле?

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

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

Изящный интерфейс, возможно — это самая важная для начала работы часть. Если вы поместите все ваши игровые объекты в вектор, система будет проходить по им всем и спрашивать у каждого объекта, имеет ли он необходимый компонент, прежде чем продолжить. Другими словами:

void my_nth_system(std::vector<game_objects> &objects) {     for(auto &&object: objects) {         if(object.has<position, velocity>()) {             auto &pos = object.get<position>();             auto &vel = object.get<velocity>();              // ...         }     } }

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

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

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

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

На пути к решению без использования объектов: сущности — это индексы

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

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

Сперва, нам необходимо дать имя нашим игровым объектам, и мы-то знаем, что выбор имени — одна из самых простых задач в программировании :). Поскольку ранее мы помещали игровые объекты в вектор, мы могли бы использовать индекс объекта в качестве его имени. Теперь первый объект имеет наименование 0, второй – 1, и так далее. Давайте назовём объекты сущностями, и мы имеем, что первая группа компонентов назначена сущности 0, а вторая группа компонентов назначена сущности 1.

Заметили в этом шаблон? Если мы перевернём проблему с ног на голову, то укладывая наши компоненты в упакованные массивы, один массив на каждый тип компонента, то на позиции 0 в каждом массиве будут лежать компоненты для сущности 0, на позиции 1 каждого массива будут лежать компоненты для сущности 1, и так далее. В общем, если мы имеем N сущностей и M разделённых массивов компонентов, то мы можем использовать саму сущность в качестве индекса для доступа к её данным в разных массивах.

У нас больше нет игровых объектов. Вместо этого, мы имеем сущности в виде чисел и экземпляры компонентов, каждый из которых размещен в своем собственном массиве. Идентификаторы сущностей также являются индексами, используемыми для извлечения экземпляров компонентов. Это более-менее вся идея, лежащая в основе entityx, довольно известной библиотеки ECS в C++.

Обычно к сущностям в этой реализации добавляется bitset для проверки наличия компонентов у них. Это решение ускоряет поиск и действует как обходной путь для другой проблемы. Рассмотрим случай, когда компонент C назначен сущности N > 0. В это случае массив для компонентов C будет изменён так, чтобы вместить по крайней мере N компонентов. Однако мы никогда не назначали C для сущности 0, хотя экземпляр уже существует в памяти. Как мы определим валидность компонента? Bitsets – это общий ответ на этот вопрос.

Одним из плюсов этой модели является то, что итерации выполняются довольно быстро, даже ещё быстрее, если bitsets используются для ускорения поиска.

Но, к сожалению, у этого подхода есть и некоторые недостатки. Очевидно, что мы теряем много памяти, в случае, когда массивы разряжены, и, по-видимому, нет простого способа избежать этого. Этот случай влечёт за собой так же менее очевидный недостаток, а именно: большое количество кеш-пропусков из-за того, что мы извлекаем из памяти также дыры, которые соседствуют с действующими компонентами. Еще одним минусом является то, что мы до сих пор не знаем, какие сущности обладают какими компонентами, и поэтому нам приходится пробегаться через их всех в каждой системе, чтобы проверить, соответствуют ли сущности требованиям. Использование bitset может смягчить этот аспект, но это не устранит проблему полностью.

Что дальше?

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

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

Дайте мне знать, если вам это помогло

Я надеюсь, вам понравилось то, что вы прочитали.

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

Спасибо.

Основные функции:
1. Паяльник. В коде заданы несколько температурных режимов (100, 250 и 350 градусов), между которыми осуществляется переключение кнопкой Solder. Плавная регулировка мне тут не нужна, паяю я в основном на 250 градусах. Мне лично это очень удобно. Для точного поддержания температуры используется PID регулятор.
Заданные режимы, пины, параметры PID можно поменять в файле 3_Solder:

struct {   static const byte   termistor   =  A2;  // пин термистора   static const byte   pwm         =  10;  // пин нагревателя   static const byte   use         =  15;  // A1 пин датчика движения паяльника   int                 mode[4]     =  {0, 150, 250, 300}; // режимы паяльника   byte                set_solder  =  0; // режим паяльника (по сути главная функция)   static const double PID_k[3]    =  {50, 5, 5};    // KP KI KD   static const byte   PID_cycle   =  air.PID_cycle; // Цикл для ПИД. Участвует в расчетах, а также управляет частотой расчетов ПИД   double PID_in;  // входящее значение   double PID_set; // требуемое значение   double PID_out; // выходное значения для управляемого элемента   //unsigned long time;   unsigned long srednee; } sol;

2. Фен. Также заданы несколько температурных режимов (переключение кнопкой Heat), PID регулятор, выключение вентилятора только после остывания фена до заданной температуры 70 градусов.
Заданные режимы, пины, параметры PID можно поменять в файле 2_Air:

struct {   static const byte   termistor     =  A3; // пин термистора   static const byte   heat          =  A0; // пин нагревателя   static const byte   fan           =  11; // пин вентилятора   int                 mode_heat[5]  =  {0, 300, 450, 600, 700}; // быстрые режимы нагревателя   byte                set_air       =  0; // режимы фена (нагреватель + вентилятор) по сути главная функция   static const double PID_k[3]      =  {10, 2, 10}; // KP KI KD   static const byte   PID_cycle     =  200; // Цикл для ПИД. Участвует в расчетах, а также управляет частотой расчетов ПИД   double PID_in;  // входящее значение   double PID_set; // требуемое значение   double PID_out; // выходное значения для управляемого элемента   unsigned long time;   unsigned long srednee;   boolean OFF = 0; } air;

Нюансы:
1. Паяльник применил от своей старой станции Lukey 936A, но с замененным нагревательным элементом на китайскую копию Hakko A1321/
2. Кнопка отключения отключает сразу все что было включено.
3. Можно одновременно включать и паяльник и фен.
4. На разъеме фена присутствует напряжение 220В, будьте осторожны.
5. Нельзя отключать паяльную станцию от сети 220В пока не остынет фен.
6. При отключенном кабеле паяльника или фена, на дисплее будут максимальные значения напряжения с ОУ, пересчитанные в градусы (не ноль). Поясню: если например просто подключить кабель холодного паяльника должен показывать комнатную температуру, при отключении покажет например 426. Какой в этом плюс: если случайно оборвется провод термопары или терморезистора, на выходе ОУ будет максимальное значение и контроллер просто перестанет подавать напряжение на нагреватель, так как будет думать что наш паяльник раскален и его нужно охладить.
7. Защиты от КЗ нет, поэтому рекомендую установить предохранители.
8. Стабилизатор на 5В для питания Arduino используйте любой доступный с учетом напряжения питания вашего БП и нагрева в случае линейного стабилизатор. Так как у меня напряжение 20В установил 7805.
9. Паяльник прекрасно работает и при 30В питания, как в моей основной паяльной станции. Но при использовании повышенного напряжения учитывайте все элементы: стабилизатор 5В и то что напряжение вентилятора 24В.

Основные узлы и состав:
1. Основная плата:
— Arduino Pro mini,
— сенсорные кнопки,
— дисплей от телефона Nokia 1202.
2. Плата усилителей:
— усилитель терморезистора паяльника,
— полевой транзистор нагрева паяльника,
— усилитель термопары фена,
— полевой транзистор включения вентилятора фена.
3. Плата симисторного модуля
— оптосимистор MOC3063,
— симистор со снабберной цепочкой.
4. Блок питания:
— блок питания от ноутбука 19В 3.5А,
— выключатель,
— стабилизатор для питания Arduino.
5. Корпус.
А теперь подробнее по узлам.
1. Основная плата.

Обратите внимание наименование сенсорных площадок отличается от фото. Дело в том, что в связи с отказом от регулировки оборотов вентилятора, в коде я переназначил кнопку включения фена. В самом начале регулировка оборотов была реализована, но так как напряжение моего БП 20В (увеличил на 1В добавлением переменного резистора), а вентилятор на 24В, решил отказаться.
Сигнал с сенсорных кнопок TTP223 (включены в режиме переключателя Switch, на пин TOG подан 3.3В) считывается Arduino. Дисплей подключен через ограничительные резисторы для согласования 5В и 3.3В логики. Такое решение не совсем правильное, но уже работает несколько лет в разных устройствах.
Основная плата двухстороннего печатного монтажа. Металлизацию оставлял по максимуму, чтобы уменьшить влияние помех, а также для упрощения схемы сенсорных кнопок (для TTP223 требуется конденсатор по входу на землю для уменьшения чувствительности. Без него кнопка будет срабатывать просто при приближении пальца. Но так как у меня сделана сплошная металлизация этот конденсатор не требуется). Сделан вырез под дисплей.

Фото платы без деталей

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

Изготовление лицевой панели

Лицевую панель, по размерам из 3Д модели, я сначала нарисовал в программе FrontDesigner-3.0_rus, в файлах проекта лежит исходник.

Распечатал, вырезал по контуру, а также окно для дисплея.
Далее заламинировал самоклеящейся пленкой для ламинирования и приклеил к плате. Дисплей за также приклеен к этой пленке. За счет выреза в плате дисплей получился вровень с основной платой.

На нижней стороне находится Arduino Pro mini и микросхемы сенсорных кнопок TTP223.
2. Плата усилителей.

Схема паяльника состоит из дифференциального усилителя с резистивным мостом и полевого транзистора с обвязкой.
1. Для увеличения «полезного» диапазона выходного сигнала при низкоомном терморезисторе (в моем случае в китайской копии Hakko A1321 56 Ом при 25 градусах, для сравнения в 3д принтерах обычно стоит терморезистор сопротивлением 100 кОм при 25 градусах) применен резистивный мост и дифференциальный усилитель. Для уменьшения наводок параллельно терморезистору и в цепи обратной связи стоят конденсаторы. Данная схема нужна только для терморезистора, если в вашем паяльнике стоит термопара, то нужна схема усилителя аналогичной в схеме фена. Настройка не требуется. Только измерить сопротивление вашего терморезистора при 25 градусах и поменять при необходимости резистор 56Ом на измеренный.
2. Полевой транзистор был выпаян из материнской платы. Резистор 100 кОм нужен чтобы паяльник сам не включился от наводок если ардуина например отключится, заземляет затвор полевого транзистора. Резисторы по 220 Ом для ограничения тока заряда затвора.
Схема фена состоит из неинвертирующего усилителя и полевого транзистора.
1. Усилитель: типовая схема. Для уменьшения наводок параллельно термопаре и в цепи обратной связи стоят конденсаторы.
2. Обвязки у полевого транзистора ME9926 нет, это не случайно. Включение ничем не грозит, просто будет крутится вентилятор. Ограничения тока заряда затвора тоже нет, так как емкость затвора небольшая.
Типоразмер резисторов и конденсаторов 0603, за исключением резистора 56 Ом — 1206.,
Настройка не требуется.
Нюансы: применение операционного усилителя LM321 (одноканальный аналог LM358) для дифферециального усилителя не является оптимальным, так как это не Rail-to-Rail операционный усилитель, и максимальная амплитуда на выходе будет ограничена 3.5-4 В и максимальная температура (при указанных на схеме номиналах) будет ограничена в районе 426 градусов. Рекомендую использовать например MCP6001. Но нужно обратить внимание что в зависимости от букв в конце отличается распиновка:

3. Плата симисторного модуля.

Схема стандартная с оптосимистором MOC3063. Так как MOC3063 сама определяет переход через ноль напряжения сети 220В, а нагрузка — нагреватель инерционный элемент, использовать фазовое управление нет смысла, как и дополнительных цепей контроля ноля.
4. Блок питания.
Выбор был сделан по габаритным размерам и выходной мощности в первую очередь. Также я немного увеличил выходное напряжение до 20В. Можно было и 22В сделать, но при включении паяльника срабатывала защита БП.
5. Корпус.
Корпус проектировался под мой БП, с учетом размеров плат и последующей печати на 3Д принтере. Металлический даже не планировался, приличный алюминиевый анодированный корпус дороговато и царапается, и куча других нюансов. А гнуть самому красиво не получится.
Разъемы:
1. Фен — «авиационный» GX16-8.
2. Паяльник — «авиационный» GX12-6.

Немного фото

Исходники лежат тут.
На этом все.
P.S. Первую версию я сохранил в черновиках на память.

Ansible отличается простотой использования, имеет безагентную архитектуру (не требует установки агента/клиента на целевую систему) и YAML-подобный DSL, написана на Python и легко расширяется за счет модулей. Обычно управляет конфигурацией Linux.

Puppet имеет клиент-серверную архитектуру (периодически опрашивает сервер, чтобы внести в конфигурацию изменения, внесенные администратором сети), написана на Ruby и имеет Ruby-подобный DSL. Это приложение позволяет централизованно управлять конфигурацией ПО, установленного на нескольких компьютерах.

В статье проводится сравнение преимуществ и недостатков этих SCM.

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

Таким образом, такие инструменты, как Puppet и Ansible, быстро становятся необходимыми компонентами управления большим количеством серверов, например, в дата-центрах. Их называют средствами управления конфигурацией (CM) и удаленного выполнения (RE) и часто используют с инструментами обновления ПО. Эти полезнейшие приложения позволяют, например, сетевому администратору выполнять действия на нескольких серверах одновременно, развертывать несколько приложений одним щелчком мыши, что значительно упрощают настройку и обслуживание десятков, сотен или даже тысяч серверов.

Ansible против Puppet: краткий обзор

Puppet — один из известнейших брендов на рынке CM. Он существует с 2005 года, что для инструментов CM равносильно существованию со времен зарождения человечества. Множество именитых клиентов, таких как Google, Reddit, Dell, PayPal, Oracle, лаборатории Los Alamos Labs и Стэндфордский университет, управляют своими дата-центрами с помощью Puppet. Наличие таких клиентов на борту всегда придает продукту определенный уровень доверия. Puppet также может похвастаться самым зрелым интерфейсом и работой на всех основных операционных системах -Linux, Windows, Unix и даже Mac OS X. Следуя модели, созданной различными версиями Linux, это приложение с открытым исходным кодом разработано на Ruby. Однако существует солидная, хорошо зарекомендовавшая себя компания поддержки и спонсорства PuppetLabs, предлагающая профессиональную поддержку и коммерческую корпоративную версию программного обеспечения.

Puppet также предлагает простую процедуру установки и несколько инструментов для таких задач, как быстрое развертывание на клиентских серверах. В дополнение к GUI есть CLI на основе Ruby. На самом деле для большинства продвинутых задач вам, скорее всего, придется зависеть от CLI, причем GUI является интерфейсом просмотра, управления и мониторинга. Это означает, что в дополнение к работе системного администратора вам потребуется изучить Ruby.

Вы можете подумать: «Все это звучит здорово! Есть ли какие-то минусы, или стоит пойти и купить Puppet прямо сейчас»?.. Спор вокруг использования этой SCM на специализированных форумах CM заключается в том, что Puppet, как и многие другие гиганты программного обеспечения, стала жертвой собственного успеха и размера. «Ловкий» и «проворный» – это не те слова, которые можно использовать для описания работы Puppet. Пользователи сообщают об ошибках, которые слишком долго исправляются, и игнорировании новых запросов. Существует также некоторое недовольство тем, что PuppetLabs настойчиво подталкивает своих клиентов к принятию коммерческой версии. Наконец, хотя Puppet поддерживает как чистый Ruby, так и его настроенный DSL на CLI, поддержка одного лишь Ruby является устаревшей. Это плохая новость для тех, кто изучал только Ruby, а не DSL.

Ansible обошел Puppet, захватив самую большую долю рынка в индустрии систем управления конфигурациями — 26,5%. За ним следует Microsoft System Center CM (21,8%) и Puppet (12%).

Это также продукт с открытым исходным кодом, который был выпущен в 2012 году и с тех пор поддерживается компанией-разработчиком AnsibleWorks. Он был разработан на Python, а не на Ruby, что делает его духовно ближе к Salt (еще один новый инструмент CM), чем Puppet. Другим преимуществом Python является то, что он встроен в большинство Unix и Linux – приложений, так что SCM, написанные на этом языке, устанавливаются и работают быстрее.

Уникальный маркетинговый ход Ansible состоит именно в легком и быстром развертывании. Фактически эта система даже не использует развертываемые агенты для связи с мастер-клиеном, вместо этого все функции выполняются через SSH. Для тех конфигураций, которые не поддерживают корневой SSH, Ansible может выполнять «sudo» как root. Ansible можно запускать из CLI без использования файлов конфигурации для простых задач, таких как проверка работы службы или запуск обновлений и перезагрузок. Для более сложных задач конфигурация Ansible обрабатывается с помощью синтаксиса YAML в конфигурационных файлах, называемых «playbooks». Команды Ansible могут быть написаны практически на любом языке программирования и распространены в виде универсальных модулей JSON, что явно является преимуществом по сравнению с выбором одного конкретного языка.

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

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

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

Различия между Ansible или Puppet становятся очевидными с момента установки систем. Поскольку они следуют различным архитектурным парадигмам, их настройка существенно отличается. Так, Ansible преследует явную цель сделать процесс настройки как можно проще, что проявляется в пользовательском опыте.

Чтобы настроить Ansible, вначале необходимо назначить один узел в качестве узла управления control node. В действительности любой из ваших узлов может быть узлом управления. Вы можете установить Ansible на этом узле с помощью последнего пакета Ansible из репозиториев пакетов вашего дистрибутива, при этом нет никакой необходимости настраивать клиентское программное обеспечение на других узлах. Просто создайте пару ключей SSH на своем узле управления, а затем скопируйте их на остальные узлы. Далее создайте файл инвентаризации для узлов Ansible — как правило, в таких ОС Linux, как Red Hat Linux, Ubuntu и Debian это происходит в /etc/ansible/hosts. Теперь вы готовы использовать Ansible для запуска PlayBook как на вашем узле управления, так и на остальной части сетевой инфраструктуры. Ansible будет использовать SSH-соединения с вашими control node для запуска управления конфигурацией на основе PlayBook.

Настройка Puppet выглядит немного сложнее, но зато в интернете есть много документации, которая поможет в трудном случае. Во-первых, вам нужно будет настроить узлы master и agent так, чтобы они имели одинаковое время и часовой пояс. Затем вам потребуется зайти на мастер-сервер с root-правами и установить серверное программное обеспечение Puppet. Далее необходимо настроить файл Puppet-мастера /etc/hosts для подключения всех управляемых клиентов, запустить службу PuppetServer и перевести ее в режим «enable» для получения клиентских подключений на порту 8140. Поскольку Puppet опирается на программное обеспечение клиентов, вам потребуется установить программные агенты Puppet на каждом из них.

Кроме того, потребуется добавить IP-адрес мастер-сервера в /etc/hosts, чтобы клиент мог к нему подключиться. Для этого вы должны запустить и включить службу Puppet agent на каждом клиенте, после чего сгенерировать SSL-сертификаты, так как эта система CM использует HTTPS для связи мастер-клиент.

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

Ansible против Puppet: масштабируемость и механизм транспортировки конфигураций

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

Ansible по умолчанию использует транспортный механизм «smart», который основан на доверенных сертификатах SSH. Ansible сначала проанализирует PlayBooks и определит затрагиваемые элементы инфраструктуры. Затем она откроет SSH-соединение и создаст временный каталог. После закрытия этого соединения Ansible открывает второе соединение для выполнения копирования поверх кода модуля Ansible и шаблонного кода Ansible. Ansible закроет это соединение перед открытием третьего, окончательного соединения для выполнения кода. Эта настройка будет служить большинству целей, но ее можно изменять по мере масштабирования инфраструктуры.

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

Транспортный механизм Puppet – это HTTPS, который управляется с помощью SSL-сертификатов. Один сервер Puppet обрабатывает запросы конфигурации целого списка клиентов Puppet. Каждый клиент отправляет Puppet-факты мастер-серверу вместе с запросом на каталог Puppet, после чего мастер-сервер отправляет в ответ этот каталог. Затем клиент обрабатывает каталог, сверяя каждый программный ресурс с требуемым состоянием конфигурации, указанным в каталоге. Если ресурс не находится в нужном состоянии, клиент Puppet обновит ресурс на данном компьютере и после завершения обновления отправит отчет о выполненном изменении конфигурации Puppet-серверу.

Примечательно, что модель обработки Puppet выделяет поток JRuby из пула потоков для обработки каждого входящего клиентского соединения. По мере увеличения числа узлов можно оптимизировать масштабирование Puppet, увеличив количество доступных в пуле потоков JRuby. Это можно проделать, установив значение параметра конфигурации Puppet “max-active-instances” выше, чем значение по умолчанию, которое равно 1. Как правило, это значение принимается равным количеству ядер процессора вашего компьютера, однако имейте в виду, что это потребует большего объема задействованной процессорной памяти CPU RAM. Как правило, вам также будет необходимо установить более высокий «максимальный размер кучи» для JVM вашего Puppet-сервера, чтобы гарантировать, что ваши дополнительные потоки JRuby могут быть выделены без возникновения ошибки виртуальной машины Java «out of memory». При выполнении этой настройки следует соблюдать осторожность, так как можно столкнуться с потерей производительности.

Пример кода CM Ansible

Для повседневной работы с конфигурацией написание кода Ansible удивительно просто благодаря сочетанию двух факторов: использованию формата YAML для PlayBooks и декларативному стилю управления конфигурацией, который отсекает «острые углы». Это важно для быстрого повышения производительности команд DevOps и обеспечения управляемости вашего кода даже для сложных задач конфигурации.

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

Ниже приведен пример кода Ansible PlayBook, который устанавливает на ваши узлы веб-сервер Tomcat. Этот пример взят с официального репозитория Ansible examples, который вам стоит просмотреть, чтобы лучше ознакомиться с идиоматическим стилем Ansible:

--- - name: Install Java 1.7 yum: name=java-1.7.0-openjdk state=present  - name: add group "tomcat" group: name=tomcat  - name: add user "tomcat" user: name=tomcat group=tomcat home=/usr/share/tomcat createhome=no become: True become_method: sudo  - name: Download Tomcat get_url: url=http://archive.apache.org/dist/tomcat/tomcat-7/v7.0.61/bin/apache-tomcat-7.0.61.tar.gz dest=/opt/apache-tomcat-7.0.61.tar.gz  - name: Extract archive command: chdir=/usr/share /bin/tar xvf /opt/apache-tomcat-7.0.61.tar.gz -C /opt/ creates=/opt/apache-tomcat-7.0.61  - name: Symlink install directory file: src=/opt/apache-tomcat-7.0.61 path=/usr/share/tomcat state=link  - name: Change ownership of Tomcat installation file: path=/usr/share/tomcat/ owner=tomcat group=tomcat state=directory recurse=yes  - name: Configure Tomcat server template: src=server.xml dest=/usr/share/tomcat/conf/ notify: restart tomcat  - name: Configure Tomcat users template: src=tomcat-users.xml dest=/usr/share/tomcat/conf/ notify: restart tomcat  - name: Install Tomcat init script copy: src=tomcat-initscript.sh dest=/etc/init.d/tomcat mode=0755  - name: Start Tomcat service: name=tomcat state=started enabled=yes  - name: deploy iptables rules template: src=iptables-save dest=/etc/sysconfig/iptables when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '6'" notify: restart iptables  - name: insert firewalld rule for tomcat http port firewalld: port=/tcp permanent=true state=enabled immediate=yes when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '7'"  - name: insert firewalld rule for tomcat https port firewalld: port=/tcp permanent=true state=enabled immediate=yes when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '7'"  - name: wait for tomcat to start wait_for: port=

Эта конкретная задача Ansible загружает и устанавливает Apache Tomcat вместе с зависимым Java JDK 1.7, а затем настраивает, запускает и обеспечивает установку Tomcat. Как видно из данного примера, файлы, управляемые Ansible, могут содержать шаблоны Jinja, что упрощает вычисление значений и делает вашу конфигурацию более гибкой. Код YAML легко читать и писать как системным администраторам, так и разработчикам. Это приводит к тому, что Ansible становится доступной системой управления конфигурацией как для продвинутых, так и для начинающих пользователей.

Пример кода CM Puppet

Предметно-ориентированный язык Puppet основан на Ruby, но его синтаксис гораздо ближе к императивным языкам в стиле C, таким как Perl, Java и C++. Этот подход является промежуточным звеном между разработчиками, знакомыми с Ruby, и теми, кто может быть незнаком с данным языком. В результате вам может вообще не понадобится знать Ruby, чтобы изучить и продуктивно использовать Puppet DSL.
Это пример манифеста Puppet из репозитория PuppetLabs MySQL Puppet Module, который устанавливает и настраивает клиентский пакет MySQL:

# @summary #     Installs and configures the MySQL client. # # @example Install the MySQL client #     class {'::mysql::client': #         package_name => 'mysql-client', #         package_ensure => 'present', #         bindings_enable => true, #     } # # @param bindings_enable #     Whether to automatically install all bindings. Valid values are `true`, `false`. Default to `false`. # @param install_options #     Array of install options for managed package resources. You must pass the appropriate options for the package manager. # @param package_ensure #     Whether the MySQL package should be present, absent, or a specific version. Valid values are 'present', 'absent', or 'x.y.z'. # @param package_manage #     Whether to manage the MySQL client package. Defaults to `true`. # @param package_name #     The name of the MySQL client package to install. # class mysql::client (     $bindings_enable = $mysql::params::bindings_enable,     $install_options = undef,     $package_ensure = $mysql::params::client_package_ensure,     $package_manage = $mysql::params::client_package_manage,     $package_name = $mysql::params::client_package_name, )  inherits mysql::params {          include '::mysql::client::install'      if $bindings_enable {         class { 'mysql::bindings':             java_enable => true,             perl_enable => true,             php_enable => true,             python_enable => true,             ruby_enable => true,         }     }  # Anchor pattern workaround to avoid resources of mysql::client::install to # "float off" outside mysql::client anchor { 'mysql::client::start': } -> Class['mysql::client::install'] -> anchor { 'mysql::client::end': } }

Важным преимуществом Puppet является то, что, в отличие от перечисленных выше императивных языков программирования, Puppet DSL является декларативным, в некотором смысле похожим на XML, а также на код YAML из приведенного выше примера кода Ansible. Декларативный подход как Puppet, так и Ansible действительно прослеживается в обоих примерах кода. С точки зрения кодирования, они похожи и ближе друг другу, чем такие инструменты, как Chef. Тем не менее, декларативный язык Puppet также предоставляет Ruby-подобные конструкции, такие как условные выражения и итерации, что опять же является компромиссным решением для пользователей Ruby и тех, кто не владеет данным языком.

Ansible против Puppet: простота использования

Для команды разработчиков простота использования должна быть важной частью оценки SCM. Учитывая, что разработчики Ansible сосредотачивают массу усилий на простоте использования системы, в этом она не имеет конкурентов. Настройка, программирование и управление узлами предоставляют очень простой интерфейс как инженерам-разработчикам, так и системным администраторам.

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

С точки зрения обучаемости пользователей обе платформы просты в использовании, но Ansible имеет небольшое преимущество. Легко добиться декларативного стиля YAML, так что код Ansible никогда не бывает слишком сложным. Тем временем Puppet пришла к осознанию некоторых проблем, связанных с объединением данных и кода в одних и тех же исходных файлах. Это привело к появлению Puppet Hiera, решения для хранения данных, которое использует формат YAML для хранения пар «ключ-значение» конфигурационных данных. Hiera проходит долгий путь к упрощению и оптимизации опыта Puppet DevOps. Формат YAML оказался довольно популярным для управления конфигурациями, причем Salt от SaltStack также использует этот формат.
Обе SCM имеют возможности для проверки и тестирования вашего СM, от проверки синтаксиса до интеграции кода «infrastructure-as-code».

Ansible против Puppet: расходы на приобретение лицензий и внедрение

Как инструменты с открытым исходным кодом, Ansible и Puppet имеют много общего в своей лицензионной политике.

Релиз Ansible с открытым исходным кодом доступен совершенно бесплатно. Компаниям, которым требуется больше гарантий безопасности, стабильности и надежности, предлагается перейти на Ansible Engine, продукт корпоративного класса, который предоставляется в Red Hat Linux. Стоимость лицензии Ansible Engine обычно составляет от $ 47,50 до $ 70 в год на узел и зависит от предпочтительной настройки.

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

Как и Ansible, релиз Puppet с открытым исходным кодом доступен бесплатно. Для получения дополнительных корпоративных функций и технической поддержки, организации могут перейти на Puppet Enterprise, стоимость которого составляет от $112 до $199 в год на 1 узел. Puppet Enterprise предлагает пакет из нескольких инструментов, включая отчетность и мониторинга состояния инфраструктуры предприятия.

Ansible против Puppet: сообщество

Puppet, выпущенный в 2005 году, является более старым инструментом DevOps, поэтому у него было больше времени для создания собственного сообщества и базы пользователей. Тем не менее, Ansible, запущенный в 2012 году, благодаря своему новому подходу, смог привлечь еще большую аудиторию и создать очень динамичное сообщество разработчиков-энтузиастов и пользователей. В число пользователей Puppet входят такие компании, как Uber, Salesforce и Paypal, а сообщество Ansible включает в себя такие компании, как Digital Ocean, 9GAG и TypeForm.

Если сравнить такой важный показатель развития продуктов open source, как число вкладчиков – участников разработки на GitHub, то Ansible с более чем 4800 вкладчиками намного превосходит Puppet с его 527 участниками разработки продукта. Развитие развития Ansible за последние годы происходило настолько стремительными темпами, что породило создание отдельного «галактического» репозитория Ansible Galaxy. Это означает, что сообщество Ansible стремиться делиться своим кодом, тем самым внося свой вклад в дальнейшее развитие продукта.

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

Обе системы имеют первоклассные инструменты для контроля жизненного цикла проекта управления конфигурацией через командную строку. И Puppet, и Ansible хорошо интегрируются с другими широко используемыми системами DevOps, такими как Docker, Kubernetes и Jenkins и облачными вычислительными платформами AWS и Azure.

Ansible против Puppet: что лучше?

В этом вопросе выбор остается только за вами. Декларативный стиль как Ansible, так и Puppet означает, что эти инструменты имеют намного больше общего, чем остальные системы управления конфигурацией. Однако, чтобы сделать оптимальный выбор, нужно обратить особое внимание на то, как потребности вашей команды сочетаются с дизайном и преимуществами конкретной SCM.
Ansible лучше подходит тем, кто интересуется конфигурацией в стиле YAML и разделяет философию Ansible – быть максимально простой, при этом достаточно быстро и параллельно управлять большим пулом машин. Кроме того, эта философия направлена на использование существующих функций SSH вместо создания пользовательских агентов.

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

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

Выводы

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

Немного рекламы 🙂

Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?