DevOps

Биллинг - это система выставления счетов клиентам за оказываемые компанией услуги и продаваемые товары. Английское слово bill переводится именно как «счёт»

Следует различать автоматизированные системы расчетов (АСР) и информационные биллинговые системы (ИБС). Первые предназначены для денежных переводов и платежей между покупателем и продавцом и имеют чисто практическое значение.

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

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

Фронтенд (англ. Front-end) — клиентская сторона пользовательского интерфейса к программно-аппаратной части сервиса.

Бекенд (англ. back-end) — программно-аппаратная часть сервиса.

Фронтенд — все, что браузер может читать, выводить на экран и / или запускать. То есть это HTML, CSS и JavaScript.

HTML (HyperText Markup Language) говорит браузеру, каково содержание страницы, например, «заголовок», «параграф», «список», «элемент списка».

CSS (Cascading Style Sheets) говорит браузеру, как отображать элементы, например, «после первого параграфа отступ в 20 пикселей» или «весь текст в элементе body должен быть темно-серым и написан шрифтом Verdana».

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

Бэкенд — все, что работает на сервере, то есть «не в браузере» или «на компьютере, подсоединенном к сети (обычно к Интернету), который отвечает на сообщения от других компьютеров».

Для бэкенда вы можете использовать любые инструменты, доступные на вашем сервере (который, по сути, является просто компьютером, настроенным для ответов на сообщения). Это означает, что вы можете использовать любой универсальный язык программирования: Ruby, PHP, Python, Java, JavaScript / Node, bash. Это также означает, что вы можете использовать системы управления базами данных, такие как MySQL, PostgreSQL, MongoDB, Cassandra, Redis, Memcached.

Структура взаимодействия бэкенда и фронтенда

Серверные приложения: В этом случае HTTP-запросы отправляются напрямую на сервер приложения, а сервер отвечает HTML-страницей.

Связь с использованием AJAX: использует для связи AJAX (Asynchronous JavaScript and XML). Это означает, что JavaScript, загруженный в браузере, отправляет HTTP-запрос (XHR, XML HTTP Request) изнутри страницы и (так сложилось исторически) получает XML-ответ. Сейчас для ответов также можно использовать формат JSON. Это значит, что у вашего сервера должна быть конечная точка, которая отвечает на запросы JSON- или XML-кодом. Два примера протоколов, используемых для этого — REST и SOAP.

Клиентские (одностраничные) приложения: AJAX позволяет вам загружать данные без обновления страницы. Больше всего это используется в таких фреймворках, как Angular и Ember. После сборки такие приложения отправляются в браузер, и любой последующий рендеринг выполняется на стороне клиента (в браузере). Такой фронтенд общается с бэкендом через HTTP, используя JSON- или XML-ответы.

Универсальные/изоморфные приложения: Некоторые библиотеки и фреймворки, например, React и Ember, позволяют вам исполнять приложения как на сервере, так и в клиенте. В этом случае для связи фронтенда с бэкендом приложение использует и AJAX, и обрабатываемый на сервере HTML.

Вне фронтенда и бэкенда

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

Легкий бэкенд: Бэкенд, в свою очередь, становится легче и легче. Такие технологии, как хранилища документов и графовые базы данных, приводят к сокращению количества обращений к бэкенду для повторного агрегирования данных. Задача клиента — уточнить, какие данные ему нужны (базы данных графов), или извлечь все различные фрагменты данных, которые ему нужны (REST API). Сейчас можно создавать бэкенд-сервисы, которые работают не постоянно, а только тогда, когда они нужны, благодаря бессерверным архитектурам, таким как AWS Lambda.

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

Неудовлетворительное время отклика. Решением этой задачи является кэширование: мы помещаем результат вычислений в некоторое хранилище (например, memcached), которое обладает отличными характеристиками по времени доступа к информации. Теперь вместо обращений к медленным, сложным и тяжелым backend’ам нам достаточно выполнить запрос к быстрому кэшу.

Пример: кэш ЦП (первого и второго уровня), буферы жесткого диска, кэш операционной системы, буфер в автомагнитоле. Буфер заранее читает данные лежащие последовательно, от текущего места чтения. Если бы он бегал по всей памяти, в буфере небыло бы смысла.

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

Мы заменяем несколько обращений к backend’у на одно обращения для построения кэша, а затем все последующие обращения будет делать через быстро работающий кэш.

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

Memcached: представляет собой огромную хэш-таблицу в оперативной памяти, доступную по сетевому протоколу. Он обеспечивает сервис по хранению значений, ассоциированных с ключами. Доступ к хэшу мы получаем через простой сетевой протокол, клиентом может выступать программа, написанная на произвольном языке программирования (существуют клиенты для C/C++, PHP, Perl, Java и т.п.).

Самые простые операции – получить значение указанного ключа (get), установить значение ключа (set) и удалить ключ (del). Для реализации цепочки атомарных операций (при условии конкурентного доступа к memcached со стороны параллельных процессов) используются дополнительные операции: инкремент/декремент значения ключа (incr/decr), дописать данные к значению ключа в начало или в конец (append/prepend), атомарная связка получения/установки значения (gets/cas) и другие.

В общем случае схема кэширования выглядит следующим образом: frontend’у (той части проекта, которая формирует ответ пользователю) требуется получить данные какой-то выборки. Frontend обращается к быстрому как гепард серверу memcached за кэшом выборки (get-запрос). Если соответствующий ключ будет обнаружен, работа на этом заканчивается. В противном случае следует обращение к тяжелому, неповоротливому, но мощному (как слон) backend’у, в роли которого чаще всего выступает база данных. Полученный результат сразу же записывается в memcached в качестве кэша (set-запрос). При этом обычно для ключа задается максимальное время жизни (срок годности), который соответствует моменту сброса кэша. Вместо memcached в некоторых проектах могут использоваться локальные файлы, иные способы хранения (другая БД, кэш PHP-акселератора и т.п.)

При этом memcached крайне нетребователен к вычислительным ресурсам: на нагруженной инсталляции процессорное время, использованное им, редко превышает 10%. Во-первых, memcached спроектирован так, чтобы все его операции имели алгоритмическую сложность, т.е. время выполнения любой операции не зависит от количества ключей, которые хранит memcached. Основными оптимизированными операциями является выделение/освобождение блоков памяти под хранение ключей, определение политики самых неиспользуемых ключей (LRU) для очистки кэша при нехватке памяти. Используется асинхронный ввод-вывод, не используются нити, что обеспечивает дополнительный прирост производительности и меньшие требования к ресурсам. По сути, можно сказать, что время отклика сервера memcached определяется только сетевыми издержками и практически равно времени передачи пакета от frontend’а до сервера memcached (RTT). Такие характеристики позволяют использовать memcached в высоконагруженных web-проектов для решения различных задач, в том числе и для кэширования данных.

Потеря ключей

Memcached не является надежным хранилищем – возможна ситуация, когда ключ будет удален из кэша раньше окончания его срока жизни. Архитектура проекта должна быть готова к такой ситуации и должна гибко реагировать на потерю ключей. Самой неприятной ситуацией является крах процесса memcached или сервера, на котором он расположен. В этой ситуации мы теряем все ключи, которые хранились в кэше. Несколько сгладить последствия позволяет кластерная организация: множество серверов memcached, по которым «размазаны» ключи проекта: так последствия краха одного кэша будут менее заметны.

Можно разделить данные, которые мы храним в memcached, по степени критичности их потери.

«Можно потерять». К этой категории относятся кэши выборок из базы данных. Потеря таких ключей не так страшна, потому что мы можем легко восстановить их значения, обратившись заново к backend’у. Однако частые потери кэшей приводят к излишним обращениям к БД.

«Не хотелось бы потерять». Здесь можно упомянуть счетчики посетителей сайта, просмотров ресурсов и т.п. Хоть и восстановить эти значения иногда напрямую невозможно, но значения этих ключей имеют ограниченный по времени смысл: через несколько минут их значение уже неактуально, и будет рассчитано новое значение.

«Совсем не должны терять». Memcached удобен для хранения сессий пользователей – все сессии равнодоступны со всех серверов, входящих в кластер frontend’ов. Так вот содержимое сессий не хотелось бы терять никогда – иначе пользователей на сайте будет «разлогинивать». Как попытаться избежать? Можно дублировать ключи сессий на нескольких серверах memcached из кластера, так вероятность потери снижается.

Ceph — свободная программная объектная сеть хранения, обеспечивающая как файловый, так и блочный интерфейсы доступа. Может использоваться на системах, состоящих как из нескольких Linux-машин, так и из тысяч узлов; встроенные механизмы продублированной репликации данных обеспечивают высокую живучесть системы, при добавлении или удалении новых узлов массив данных автоматически перебалансируется с учётом изменений.

https://habr.com/ru/post/313644/

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

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

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

Поверх операционной системы работают демоны Ceph, выполняющие различные роли кластера. Таким образом один сервер может выступать, например, и в роли монитора (MON), и в роли хранилища данных (OSD). А другой сервер тем временем может выступать в роли хранилища данных и в роли сервера метаданных (MDS). В больших кластерах демоны запускаются на отдельных машинах, но в малых кластерах, где количество серверов сильно ограничено, некоторые сервера могут выполнять сразу две или три роли.

В документации перечислено 3 вида демонов:
Mon — демон монитора
OSD — демон хранилища
MDS — сервер метаданных (необходим только в случае использования CephFS)

Структура хранения

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

Фактор репликации — это уровень избыточности данных. Количество копий данных, которое будет храниться на разных дисках. За этот параметр отвечает переменная size.

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

Плейсмент-группы — это такое связующее звено между физическим уровнем хранения (диски) и логической организацией данных (пулы).

Монитор — это демон, выполняющий роль координатора, с которого начинается кластер. Как только у нас появляется хотя бы один рабочий монитор, у нас появляется Ceph-кластер. Монитор хранит информацию о здоровье и состоянии кластера, обмениваясь различными картами с другими мониторами. Клиенты обращаются к мониторам, чтобы узнать, на какие OSD писать/читать данные. Главное, чтобы количество оных было нечетным, дабы избежать ситуаций раздвоения сознания (split-brain). Мониторы работают в кворуме, поэтому если упадет больше половины мониторов, кластер заблокируется для предотвращения рассогласованности данных.

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

Один монитор и один OSD — минимальный набор для того, чтобы поднять кластер и начать им пользоваться.

Диск OSD состоит из двух частей: журнал и сами данные. Соответственно, данные сначала пишутся в журнал, затем уже в раздел данных.

Кеширование

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

Primary-Affinity (KOLHOZ)
У каждого OSD есть несколько весов, и один из них отвечает за то, какой OSD в плейсмент-группе будет первичным. А, как мы выяснили ранее, клиент пишет данные именно на первичный OSD. Так вот, можно добавить в кластер пачку SSD дисков, сделав их всегда первичными, снизив вес primary-affinity HDD дисков до нуля. И тогда запись будет осуществляться всегда сначала на быстрый диск, а затем уже не спеша реплицироваться на медленные. Этот метод самый неправильный, однако самый простой в реализации.

Вынос журналов на SSD
Вообще, львиная доля производительности зависит от журналов OSD. Осуществляя запись, демон сначала пишет данные в журнал, а затем в само хранилище. Это верно всегда, кроме случаев использования BTRFS в качестве файловой системы на OSD, которая может делать это параллельно благодаря технике copy-on-write, но я так и не понял, насколько она готова к промышленному применению. Недостаток метода в том, что при вылете SSD с журналом, мы потеряем сразу несколько OSD, что не очень приятно и вносит дополнительные трудности во всю дальнейшую поддержку, которая скалируется с ростом кластера.

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

https://habrahabr.ru/company/oleg-bunin/blog/313364/
https://habr.com/ru/company/oleg-bunin/blog/313330/

Почему LUA. Без помощи cgi, fastcgi и других cgi прямо в конфигурационном файле nginx можно заскриптовать мощный, красивый и быстрый функционал. Все работает асинхронно. Причем не только с клиентами, но и с бекендами.

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

Пример: Hello world
https://dizballanze.com/ru/primenenie-nginx-lua-dlia-obrabotki-prostykh-form/

NGINX API for Lua
https://www.nginx.com/resources/wiki/modules/lua/#nginx-api-for-lua

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

Просмотреть текущие настройки:

sudo iptables -L -n

• Chain INPUT - входящий
• Chain OUTPUT - исходящий
• Chain FORWARD - маршрутизируемый

Существует три типа правил iptables — input, forward и output.

• Input — Такие цепочки используются для контроля поведения входящих соединений. К примеру, если пользователь попробует подключиться к серверу по SSH, то iptables сравнит его IP-адрес со своим списком, чтобы разрешить или запретить доступ.
• Forward — Правила этого типа используются для обработки входящих сообщений, конечный пункт назначения которых не является текущим сервером. К примеру, в случае маршрутизатора, к нему подключаются многие пользователи и приложения, но данные не посылаются на сам маршрутизатор, они лишь передаются ему, чтобы он мог перенаправить их адресату. Если вы не занимаетесь настройкой маршрутизации или NAT, то правила этого типа использовать в работе не будете.
• Output — Такие цепочки используются для исходящих соединений. К прмиеру, если пользователь пытается отправинг запрос ping к сайту 1cloud.ru, iptables изучит цепочку правил, чтобы понять, что нужно делать в случае ping и этого сайт, и только потом разрешит или запретит соединение.

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

Действия с соединениями:

• Accept — разрешить соединение;
• Drop — игнорировать соединение, вести себя так, будто его никогда не было. Действие подходит для случаев, когда нужно сделать так, чтобы источник запроса не узнал о его блокировке.
• Reject — заблокировать соединение и отправить в ответ сообщение об ошибке. Действие подходит для тех случаев, когда владелец сервера хочет дать понять, что соединение заблокировано файрволом.

Пример для SSH:

sudo iptables [-A добавляет запись в конец][цепочка INPUT][-p протокол tcp][порт -dport][действие ACCEPT]
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
 
sudo iptables [-I добавляет в указанный порядок INPUT][указали позицию INPUT 2][-p протокол tcp][порт -dport][действие ACCEPT]
sudo iptables -I INPUT 2 -p tcp --dport 22 -j ACCEPT

Для внутренней подсети:

sudo iptables [-A добавляет запись в конец][цепочка INPUT][-s источник][-p протокол tcp][порт -dport][действие ACCEPT]
sudo iptables -A INPUT -s 10.16.103.0/24 -p tcp --dport 80 -j ACCEPT

Просмотреть порядок правил:

sudo iptables -L -n --line-numbers

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

Сделаем весь трафик DROP не указанный правилами [-P policy]:

sudo iptables -P INPUT DROP

Удалить строку [-D]:

sudo iptables -D INPUT 3

сохранить правила:

# ставим доп пакет
sudo apt-get install iptables-persistent
# сохранить
sudo service netfilter-persistent save

Состояния
В системе netfilter, каждый пакет проходящий через механизм определения состояний, может иметь одно из четырёх возможных состояний:

• NEW — пакет открывает новый сеанс. Классический пример — пакет TCP с флагом SYN.
• ESTABLISHED — пакет является частью уже существующего сеанса.
• RELATED — пакет открывает новый сеанс, связанный с уже открытым сеансом. Например, во время сеанса пассивного FTP, клиент подсоединяется к порту 21 сервера, сервер сообщает клиенту номер второго, случайно выбранного порта, после чего клиент подсоединяется ко второму порту для передачи файлов. В этом случае второй сеанс (передача файлов по второму порту) связан с уже существующим сеансом (изначальное подсоединение к порту 21).
• INVALID — все прочие пакеты.

Подробнее просмотреть маршруты v...vvvvv:

sudo iptables -L -vv

Таблица NAT:

iptables -L -t nat

Sphinx — хранилище для построения поисковых движков. Встроенный Sphinx-клиент позволяет MariaDB обмениваться данными с searchd, выполнять поисковые запросы и получать результаты поиска;

Sphinx - поисковый сервер и открытым исходным кодом (Open Source Search Server) для индексации контента из баз данных и осуществления полнотекстового поиска, разработанный Андреем Аксеновым.

Сфинкc — это бесплатный полнотекстовый поисковый движок, написанный на C++. С быстрой индексацией документов, стоп-словами, умеет интегрироваться с самыми известными БД: Mysql, MsSql, Oracle и тд, также имеет АПИ с популярными языками программирования PHP, Perl, Java и т.д. И! Имеет поддержку SQL синтаксиса.

Конфигурации Sphinx должны храниться в файле sphinx.conf в каталоге /etc/sphinxsearch. Они состоят из трёх основных блоков: index, searchd и source.

MariaDB Galera Cluster является открытым исходным кодом и бесплатным синхронным мульти-мастер-кластером для базы данных MariaDB. Он доступен только в Linux и поддерживает только системы хранения XtraDB / InnoDB. Существует экспериментальная поддержка MyISAM, но она недостаточно проверена. Начиная с MariaDB 10.1, wsrep API для Galera Cluster включен по умолчанию.

Преимущества кластера Galera

• True Multi-master. Чтение и запись на любой узел в любое время.
• Синхронная репликация. Отсутствует ведомое устройство, данные не теряются при сбое узла.
• Tightly Coupled. Все узлы имеют одинаковое состояние. Нет разнесенных данных между разрешенными узлами.
• Многопоточный Slave. Для лучшей производительности. Для любой рабочей нагрузки.
• Нет операций переключения мастер-слэйва или использования VIP.
• Горячий режим ожидания. Отсутствие простоев при переходе на другой ресурс (так как нет перехода на другой ресурс).
• Автоматическое создание узлов. Не нужно вручную создавать резервную копию базы данных и копировать ее на новый узел.
• Поддерживает InnoDB.
• Прозрачный для приложений. Требуется минимальные изменения в приложении или вообще не трубует изменений.
• Нет необходимости разделения чтения и записи.
• Результатом этого является решение высокой доступности, которое является одновременно надежным с точки зрения целостности данных и высокой производительности с отказоустойчивостью.

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

1. Между двумя центрами обработки данных (кластер для центров обработки данных). Для целей безопасности вы должны настроить VPN и MariaDB через SSL .
2. В вашей локальной сети / VLAN (единый кластер центра обработки данных) — VPN не требуется, но вы должны настроить MariaDB через SSL .

Что нужно для установки кластера высокой доступности MariaDB Galera?

• Минимум два сервера (могут быть облачные или физические). Для промышленного используйте четыре сервера (рекомендуется минимум три сервера).
• Частная сеть (LAN / VLAN) между серверами
• VPN между двумя центрами обработки данных, если устанавливается между двумя IDC
• Ubuntu Linux 16.04 LTS на обоих серверах

Данная программа позволяет средствами rsync делать резервное копирование сразу же по появлению нового файла в указанной директории (а-ля Dropbox)

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

Lsyncd — демон, который следит за изменениями в локальной директории, агрегирует их, и по прошествии определенного времени стартует rsync для их синхронизации.

Итак, rsync'ать все сразу мы не можем, зато можем обновлять только то, что изменилось. О последнем нам расскажет inotify, подсистема ядра, уведомляющий приложения об изменениях в файловой системе. Lsyncd следит за событиями изменения локального дерева файлов, собирает эту информацию за 10 секунд (можно указать любое другое время) либо пока не соберется 1000 событий (смотря какое событие произойдет первым), и запускает rsync для отправки этих файлов на остальные ноды в нашем кластере. Запускается rsync с параметром update, то есть файл на получателе будет заменен отправляемым только если последний новее. Это дает возможность избежать коллизий и лишних операций (например, если один и тот же файл был сгенерирован параллельно и на отправителе, и на получателе).

Lsyncd просматривает дерево локальных директорий с помощью интерфейса модуля мониторинга inotify. Он агрегирует и комбинирует события за несколько секунд и затем запускает процесс (или несколько процессов) синхронизации изменений. По умолчанию для этих целей используется rsync. Таким образом, lsyncd - легковесное решение для зеркалирования данных, сравнительно легкое в установке, не требующее специфичных файловых систем или блочных устройств, а также не влияющее на производительность файловой системы. Ниже я синхронизирую данные с моего клиентского компьютера под управлением Mint 12/Ubuntu на NAS сервер (Synology DS211J).

Maven — инструмент для автоматизации сборки проектов. С ним работают в основном Java-разработчики, хотя есть плагины для интеграции с C/C++, Ruby, Scala, PHP и другими языками. В статье будут рассмотрены особенности и область применения Maven, описан процесс установки и начала работы, а также разобрана структура файла описания проекта.

Назначение и особенности
Собрать на Java проект уровня «Hello, world!» можно и с помощью командной строки. Но чем сложнее разрабатываемое ПО и чем больше оно использует сторонних библиотек и ресурсов, тем сложнее будет команда для сборки. Maven разработан для облегчения этой работы.

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

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

Разработчики также подчёркивают независимость фреймворка от ОС. При работе из командной строки параметры зависят от платформы, но Maven позволяет не обращать внимания на этот аспект.

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

В этой статье мы будем работать с Maven с помощью командной строки, однако этот фреймворк также интегрирован в Eclipse, IntelliJ IDEA, NetBeans и другие IDE.

BGP — это протокол динамической маршрутизации, являющийся единственным EGP( External Gateway Protocol) протоколом. Данный протокол используется для построения маршрутизации в интернете. Рассмотрим как строится соседство между двумя маршрутизаторами BGP. Соседство внутри одной автономной системы — AS 10.

Итак, что такое BGP? BGP — это протокол динамической маршрутизации, являющийся единственным EGP( External Gateway Protocol) протоколом. Данный протокол используется для построения маршрутизации в интернете. Рассмотрим как строится соседство между двумя маршрутизаторами BGP.

Протокол BGP предназначен для обмена информацией о достижимости подсетей между автономными системами (АС, англ. AS — autonomous system), то есть группами маршрутизаторов под единым техническим и административным управлением, использующими протокол внутридоменной маршрутизации для определения маршрутов внутри себя и протокол междоменной маршрутизации для определения маршрутов доставки пакетов в другие АС. Передаваемая информация включает в себя список АС, к которым имеется доступ через данную систему. Выбор наилучших маршрутов осуществляется исходя из правил, принятых в сети.

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

BGP, наряду с DNS, является одним из главных механизмов, обеспечивающих функционирование Интернета.

BGP является протоколом прикладного уровня и функционирует поверх протокола транспортного уровня TCP (порт 179). После установки соединения передаётся информация обо всех маршрутах, предназначенных для экспорта. В дальнейшем передаётся только информация об изменениях в таблицах маршрутизации. При закрытии соединения удаляются все маршруты, информация о которых передана противоположной стороной.

Rancher – это популярная открытая платформа для управления контейнерами. Выпущенный в начале 2018 года, Rancher 2.X работает в Kubernetes и включает новые инструменты, такие как управление несколькими кластерами и встроенные конвейеры CI.

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

Rancher 1.0 вышел в марте прошлого года, и на сегодняшний день в мире, по данным компании Rancher Labs, насчитывается более 10 тысяч его действующих инсталляций и более 100 коммерческих пользователей. Первая версия Rancher включала в себя Cattle, который, будучи «высокоуровневым компонентом, написанным на Java», назывался «базовым движком оркестровки» и «основным циклом всей системы». В сущности же Cattle был даже не фреймворком для оркестровки контейнеров, а специальной прослойкой, управляющей метаданными (+ ресурсами, взаимосвязями, состояниями и т.п.) и передающей все реальные задачи на исполнение внешним системам.

Версия 2.0:
"разработчики Rancher представили предварительный релиз своей будущей крупной версии — 2.0, — попутно объявив о переходе на Kubernetes в качестве единой основы для оркестровки контейнеров."

Kubernetes: вчера, сегодня, завтра
В 2015 году, когда в Rancher Labs начинали работать с Kubernetes, т.е. добавлять её поддержку в свою платформу, основной проблемой в K8s, со слов разработчиков, была установка и первичная настройка системы. Поэтому гордость анонса первичной поддержки Kubernetes в релизе Rancher v0.63 (17 марта 2016) звучала так: «Теперь вы можете запустить окружение Kubernetes в один клик и через 5—10 минут получить доступ к полностью развёрнутому кластеру».

Rancher 2.0

Как и в Rancher 1.0, в версии 2.0 платформу составляют сервер (для управления всей инсталляцией) и агенты (устанавливаются на все обслуживаемые хосты). Основное отличие Rancher 2.0 от 1.0 заключается в том, что теперь в сервер встроен Kubernetes. Это означает, что при запуске Docker-образа rancher/server стартует кластер Kubernetes, и каждый новый добавляемый хост становится его частью (имеет kubelet). Кроме того, можно создавать дополнительные кластеры в дополнение к этому мастеру, а также импортировать уже существующие кластеры с помощью kops или от внешних поставщиков вроде Google (GKE). Агент Rancher запускается на всех встроенных и импортированных кластерах.

Proxmox Virtual Environment (Proxmox VE) — система виртуализации с открытым исходным кодом, основанная на Debian GNU/Linux. Разрабатывается австрийской фирмой Proxmox Server Solutions GmbH, спонсируемой Internet Foundation Austria.

В качестве гипервизоров использует KVM и LXC (начиная с версии 4.0, в версиях до 3.4 включительно вместо него использовался OpenVZ[2]). Соответственно, способна выполнять любые поддерживаемые KVM ОС (Linux, *BSD, Windows и другие) с минимальными потерями производительности и Linux без потерь.

Гиперви́зор (англ. Hypervisor) или монито́р виртуа́льных маши́н (в компьютерах) — программа или аппаратная схема, обеспечивающая или позволяющая одновременное, параллельное выполнение нескольких операционных систем на одном и том же хост-компьютере. Гипервизор также обеспечивает изоляцию операционных систем друг от друга, защиту и безопасность, разделение ресурсов между различными запущенными ОС и управление ресурсами.

Гипервизор также обязан предоставлять работающим под его управлением на одном хост-компьютере ОС средства связи и взаимодействия между собой (например, через обмен файлами или сетевые соединения) так, как если бы эти ОС выполнялись на разных физических компьютерах.

Гипервизор сам по себе в некотором роде является минимальной операционной системой (микроядром или наноядром). Он предоставляет запущенным под его управлением операционным системам службу виртуальной машины, виртуализируя или эмулируя реальное (физическое) аппаратное обеспечение конкретной машины. И управляет этими виртуальными машинами, выделением и освобождением ресурсов для них. Гипервизор позволяет независимое «включение», перезагрузку, «выключение» любой из виртуальных машин с той или иной ОС. При этом операционная система, работающая в виртуальной машине под управлением гипервизора, может, но не обязана «знать», что она выполняется в виртуальной машине, а не на реальном аппаратном обеспечении.

Proxmox - управление виртуальными машинами и администрирование самого сервера производятся через веб-интерфейс либо через стандартный интерфейс командной строки Linux.

Для создаваемых виртуальных машин доступно множество опций: используемый гипервизор, тип хранилища (файл образа или LVM), тип эмулируемой дисковой подсистемы (IDE, SCSI или VirtIO), тип эмулируемой сетевой карты, количество доступных процессоров и другие.

Datadog — это служба мониторинга сети, которая помогает компаниям получить представление о производительности приложений. Он предоставляет обзор продукта для одного запроса SQL и соотносит производительность или ошибки приложения с показателями инфраструктуры и событиями. Программное обеспечение может помочь выявить узкие места производительности в коде или инфраструктуре и отслеживает хосты или контейнеры. Лучшее в этом приложении — то, что оно может автоматически отслеживать запросы в различных библиотеках и инфраструктурах и позволяет автоинструменту собирать промежуток от внешнего интерфейса до внутреннего. Он собирает данные из компонентов инфраструктуры, таких как поиск Redis и Elastic, и предлагает интеграцию с веб-фреймворком, таким как Ruby, Gin, Rails и т. Д. Как и другие аналогичные программы, он также предоставляет панель мониторинга в режиме реального времени со смешиванием и сопоставлением метрик и событий из подключенных приложения, хосты, сервисы и контейнеры. Пользователь может накладывать маркеры событий на графики для анализа корреляции, а также может создавать новые панели мониторинга, используя простой интерфейс перетаскивания и множество других виджетов. Datadog предлагает разные тарифные планы; У каждого плана есть своя цена и особенности. Попробуйте, если вы действительно получаете представление о производительности приложения.

Аналоги: New Relic и Atatus

Не будет лишним напомнить, что Datadog отлично интегрируется с NGINX Ingress и позволяет производить сквозную трассировку с момента поступления запроса в кластер, а также позволяет принимать метрики statsd, собирать логи и метрики хостов.

Огромный плюс Datadog в том, что его цена складывается из мониторинга инфраструктуры, APM, Log Management и Synthetics test, т.е. можно гибко подобрать план.

Chef — система управления конфигурациями, написанная на Ruby (клиентская часть) и Erlang (серверная часть), с использованием предметно-ориентированного языка для описания конфигураций. Используется для упрощения задач настройки и поддержки множества серверов и может интегрироваться в облачные платформы, такие как Rackspace и Amazon EC2, для автоматизации управления текущими процессами настройки новых серверов.

Пользователь Chef создаёт определенные «рецепты» с описанием того, как управлять серверными приложениями (например, Apache, MySQL или Hadoop) и их настроек.

Инфраструктура

• Nodes (Ноды) — это любой, ваш сервер, физический либо виртуальный, который вы будете настраивать с помощью Chef.
• The Server (Chef-сервер) — непосредственно сам Chef-сервер к которому обращаются клиенты (Nodes), сервер состоит из нескольких компонентов:
• Web-UI — приложение на RoR представляющее собой веб-интерфейс для сервера;
• Erchef — ядро сервера, начиная с Chef 11.x написано, Erlang, полностью совместимо с прежней версией на Ruby;
• Bookshelf — хранилище для “поваренных книг”;
• Nginx — идет в комплекте, все API-запросы проходят через него;
• PostgreSQL — также включен в состав Chef-сервера, очевидно выполняет роль хранилища информации.
• Workstations (рабочая станция) — рабочее место администратора Chef, т.е. ваш ПК на котором вы будет подготавливать рецепты, поваренные книги и управлять всей кухней с помощью knife.
• Knife — какой шеф-повар без ножа? Knife это основной инструмент для работы с Chef из консоли. Именно с помощью “ножа“ вы будете управлять нодами и Chef-сервером.

Подготовка рецептов:

• Сookbook (поваренная книга) — хранилище атрибутов, рецептов, шаблонов и файлов.
• Attribute (аттрибуты) — некие параметры конфигураций которые вы можете задавать для нод как через рецепты, так и через роли, рекомендую ознакомится с порядком применения атрибутов здесь.
• Templates (шаблоны конфигов) — вы можете распространять конфигурации как обычными файлами так параметризированными erb-шаблонами. Значения параметров шаблона в определенном порядке подставляются из атрибутов поваренных книг либо из ролей.
• Files — любые файлы, которые вы сможете распространять с помощью рецептов предварительно описав их путь назначения и права.
• Definitions (определения) — используются для описания новых или существующих ресурсов (напрмер служба, или виртуальный хост apache) и/или действий над ними.
• Libraries (библиотеки) — ни что иное как вставки кода на Ruby, в качестве расширений для рецептов.
• Resources (ресурсы) — ресурс это любой объект системы — файл, пользователь, группа, сервис и пр.

Подробнее: https://habr.com/ru/company/southbridge/blog/208858/

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

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

Ресурсы:

• Ресурс — это самая мелкая единица абстракции в Puppet. Ресурсами могут быть:
• файлы;
• пакеты (Puppet поддерживает пакетные системы многих дистрибутивов);
• сервисы;
• пользователи;
• группы;
• задачи cron;
• и т. д.

Подробнее:
https://habr.com/ru/post/163811/
https://habr.com/ru/post/316400/

«Обычный режим» , иногда 2 раза;
«Режим ввода» - i
«Командный режим» :

«Режим поиска» - ввод поискового запроса. Переход в него из обычного режима
/ , поиск от курсора до конца документа
? , поиск от курсора до начала документа

i — перейти в режим ввода с текущей позиции
yy (также Y) — копирование текущей строки в буфер;
p — вставка содержимого буфера под курсором.
S - удаляет всю текущую строку и переходит в режим ввода.
u — отмена последней команды;
:q! - выйти без сохранения;
:wq - записать файл и выйти;
V подсветка текста

Установка:

sudo apt update
sudo apt install git

Глобальные данные:

git config --global user.name "DebUser"
git config --global user.email "user@localhost"
# чтобы просмотреть эти данны
git config -l

Начало работы с гитом "локальное хранилище":

# инициализируем папку, появиться папка .git
git init 
# добавить папку, файл в локальный репозиторий (они перейдут в статус ожидания)
git add ["файл" или "папка" или "." - все файлы или "*.html" или "css/style.css" или "css/**/*.css"]
# шаблон НЕ добавления [!index.html] или в файл игнор
# проверить статус файлов (на данном этапе можно удалить файл из статуса ожидания)
git status
# Делаем commit, проект попадет в локальное хранилище
git commit -m "ваш текст"
# проверить логи
git log

Игнорировать файлы от git:
Создадим файл .gitignore, а внутри пишем:

*.txt
index.html
/css

Как работать с коммитами локально:

# команда выдаст историю коммитов с их ID 
git log --oneline
# посмотреть конкретный коммит и что в нем было
git checkout [ID]
# мы увидим проект на той стадии коммита когда он был сделан, ничего исправлять в нем не стоит!
# чтобы вернуть обратно
git checkout master
 
# чтобы локально отменить коммит (появиться запись об отмене, он не удаляется, отменяется)
git revert [ID]
# выход как в VIM :qw
 
# полное удаление коммита после определенного, от которого укажем ID
# лучше не использовать! удаляет коммит, но не файлы!
git reset [ID]
 
# полное удаление + файлы, вернет в состояние до конкретного коммита и файлов
git reset [ID] --hard

Локальная работка с ветками:

# создать новую ветку forum
git branch forum
# проверим текущую ветку
git status
On branch master
# перейти в свою ветку
git checkout forum
git status
On branch forum
# посмотреть ветки проекта
git branch -a
* forum
master
# чтобы перейти обратно в ветку мастер:
git checkout master

Создадим еще одну ветку, НЕ используя branch

git checkout -b admin
# мы сразу попадем в созданную ветку
Switched to a new branch 'admin'
# чтобы добавить все в ЛОКАЛЬНЫЙ репозиторий используем
git add .
git commit -m 'new'

Чтобы слить ветки, надо перейти в ветку мастер и ввести команду:

git merge forum

Подключить git к удаленному репозиторию:

git remote add origin [link_git_http]
# проверка подключения к удаленному репозиторию
git remote
origin
# закинем на удаленный репозиторий
git push -u origin [ветка:master или forum]

Начать работать с проектом от работодателя:

git clone [link_git_http]
# перейти в папку проекта
# Первый сотрудник: создает новый файл или каталог, делает add, commit, push -u...
# Второй сотрудник: как он увидит правки?
# он вводит команду для загрузки новый данных. Pull проверит репозиторий и скачает все новые файлы
git pull

1. iptables (под root):

echo $(which iptables)
/usr/sbin/iptables

2. Путь до любой команды (под root):

which cat
/usr/bin/cat
which iptables
/usr/sbin/iptables

для просмотра логов определенного сервиса или загрузки системы необходимо использовать утилиту journalctl
sudo journalctl -fe
traceroute
ip r
nmcli connection up|down имяVPN (выключить включить)
Утилита nmcli отлично подходит для управления сетевыми соединениями, для выполнения настроек и для решения других подобных задач. С её помощью можно управлять программой NetworkManager и модифицировать сетевые параметры различных устройств.
sudo journalctl -feu NetworkManager
nmcli connection edit [файл профиля] + print