Русский
Русский
English
Статистика
Реклама

Серверное администрирование

Решаем, нужен ли вам личный почтовый сервер

09.09.2020 12:15:30 | Автор: admin

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

Еще у части специалистов есть пунктик на тему красоты почты. Хочется красивый, короткий, запоминающийся адрес, который бы показывал, что вы не просто gmail-холоп, а вполне самостоятельная боевая единица на полях IT-сражений. А кто-то хочет просто экспериментов. Эти люди уже сами собирали ядро системы, тонко настроили домашний медиа-сервер, научили роутер качать все подряд с файлообменников без участия ОС. Теперь нужно поднять свою почту, приватный VPN, а дальше можно посмотреть в сторону написания драйверов или на другие активности уровня хардкор.

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

Я не хочу, чтобы мою почту читали


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

Вариант первый это использовать внекорпоративные почтовые сервисы, которые были созданы, фактически, вашими же единомышленниками.

Самый яркий и популярный пример из числа независимых почтовых сервисов ProtonMail. Этот сервис создан специально для людей, с повышенным градусом паранойи. Никаких сохранить пароль или запомнить меня на этом устройстве при включенном двухфакторе. Каждый раз логинимся руками, каждый раз вводим авторизационный код, который приходит на телефон. Сервис хорошо работает по системе email over Tor, то есть в отличие от прочих сервисов, дружит с луковкой. Но из-за повышенного градуса той самой паранойи, ProtonMail не слишком хорошо работает с SMTP и имеет ряд других болезней, свойственных андерграудным проектам. Например, администрация ProtonMail официально признавала проблемы с регистрацией на некоторых популярных сайтах и сервисах с их адресов.

Кроме ProtonMail существует еще масса сервисов этот просто наиболее известный и был приведен в качестве примера. Стоит помнить, что чем меньше почтовый сервис тем больше к нему недоверия со стороны остальной сети.

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

Если переход на другой почтовый сервис или полумеры в виде игр с настройками приватности вас не устраивают, то да вам нужен свой почтовый сервер.

Мне нужна красивая почта


Избавиться от gmail, yandex или другого индекса в адресе электронной почты мечта многих специалистов, особенно, если вы фрилансер. Временами бывает неловко при обмене электронной почтой по работе давать свои адрес вида yabestpazrab@gmail.com в ответ на manager@companyname.com. У многих возникает ощущение, что они не специалисты, а самозванцы. Вон, даже настоящей рабочей почты нет.

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

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

Мне. Нужен. Свой. Почтовый. Сервер.


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

В первую очередь, чтобы поднять свой почтовый сервер на понадобятся три составляющие:

  1. Понимание того, что свой почтовый сервер в 2020 это просто;
  2. Сервер, на котором все будет крутиться-вращаться;
  3. Личный домен.

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

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

Чтобы вы понимали, насколько это было давно. В 2000 году релизнули первую версию Symbian, AMD представила революционный Athlon с частотой 1 GHz, вышла в свое Windows 2000, а на прилавках появилась PlayStation 2. В тот же год начал лопаться пузырь доткомов, а Bon Jovi выпустил сингл Its My Life.

И вот примерно из той эпохи и произрастают представления о почтовых серверах тех, кто толком с ними никогда не имел дела. На самом деле сейчас все намного проще.

Первый шаг по поднятию почтового сервера поиск подходящего вам доменного имени, на которое мы повесим все хозяйство. Где покупать домены дело ваше. Можно за границей, можно у reg.ru или другого крупного местного продавца, тут дело исключительно вкуса.

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

Третий шаг может быть двух типов. Простой и сложный.

Простой вариант выглядит как покупка VPS с Ubuntu и команда в консоли:

# apt install postfix

В процессе установки указываем в качестве интернет-сайта ваш личный домен, а в параметре mydestination указываем

mydestination = $mydomain, localhost.$mydomain, localhost

Уходим на ребут и все! Вы невероятны и с собственным почтовым сервером!

Есть вариант посложнее для тех, кто предпочитает все контролировать.

Вместо почти стандартного уже Postfix, разработка которого началась еще в 1998 году, вы можете выбрать любой другой сервер, например Qmail, Exim, Citadel, Zimbra, или даже платный MailerQ. В поиске чаще всего упоминаются именно эти ребята.

Например, Exim родом из кабинетов Кембриджского Университета, распространяется свободно по лицензии GNU, а разработка ведется еще с 90-х годов. Из приятного: по этому серверу есть вся возможная документация, так как ваялось это, очевидно, не на коленке. Имеет достаточно широкий набор готовых конфигураций под Unix-системы, в том числе под не слишком известные и местами специфические дистрибутивы.

Актуальный список систем, для которых есть стоковые конфиги
AIX, BSD/OS (aka BSDI), Darwin (Mac OS X), DGUX, Dragonfly, FreeBSD, GNU/Hurd, GNU/Linux, HI-OSF (Hitachi), HI-UX, HP-UX, IRIX, MIPS RISCOS, NetBSD, OpenBSD, OpenUNIX, QNX, SCO, SCO SVR4.2 (aka UNIX-SV), Solaris (aka SunOS5), SunOS4, Tru64-Unix, Ultrix, и UnixWare.

Exim легкий, с широкими возможностями и жирной документацией вариант для людей, готовых поработать над настройкой. Единственное, что омрачает картину эксплуатация уязвимости Exim летом 2019 года в версиях 4.87-4.91 (актуальная 4.94). Тогда под удар попали миллионы почтовых серверов, а сам эксплоит оценили на 9,8 из 10. Подробнее можно почитать тут и тут, писали на Хабре.

Настолько же древним мастодонтом является и Qmail, первая версия которого вышла почти 25 лет назад, в декабре 1995 года. Он прост, быстр, надежен как швейцарские часы и является одним из самых популярных SMTP-серверов в интернете.

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

Также внимательный администратор озаботится настройкой анти-спам защиты. По этому запросу поисковик может посоветовать вам SpamAssassin, который упоминается в ряде материалов по теме за последние 5 лет, в том числе в одной из наших статей. Этот проект стагнировал с 2015 по 2018 годы, так что захотите ли вы им пользоваться сейчас вопрос открытый. Последнее обновление SpamAssassin вышло в январе этого года и в целом, патчи он получает +\- раз в год. Но SpamAssassin'у есть масса альтернатив, тот же rspamd. Вообще, о ручной настройке почтового сервера мы писали еще в 2017 году, почитайте, там разложены основные моменты, с которыми вам придется иметь дело. Само собой, еще большую ценность представляют комментарии к ней, как это обычно бывает на Хабре.

Так нужен ли почтовый сервер или нет


Собственно, идея проста: персональный почтовый сервер в 2020 году это сравнительно просто, если не углубляться в конфигурацию, и сравнительно доступно.

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

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

В 100% случаев свой почтовый сервер это поле для экспериментов и получение навыков настройки и администрирования, ну и, конечно же, средство для борьбы со слежкой или собственной паранойей на эту же тему. Что в современных реалиях почти одно и тоже и не осуждается.

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



Подробнее..

Jekyll на VPS за 30 рублей для состоятельных людей

11.09.2020 16:15:38 | Автор: admin

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

Шаг 1. Хостинг: берем самый дешевый на рынке


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

Сегодня мы в RUVDS снова открываем тариф ПРОМО за 30 рублей, позволяющий арендовать виртуальную машину на Debian, Ubuntu или CentOS. На тарифе есть ограничения, но за смешные деньги вы получите одно вычислительное ядро, 512 МБ оперативной памяти, SSD на 10 ГБ, 1 IP и возможность запуска любых приложений.

Давайте на нем и развернем наш Jekyll-блог.



После запуска VPS на него надо зайти по SSH и настроить необходимое ПО: веб-сервер, сервер FTP, почтовый сервер и т.д. При этом пользователю не придется устанавливать Jekyll на собственном компьютере или терпеть ограничения хостинга GitHub Pages, хотя исходники сайта можно держать в репозитории GitHub.

Шаг 2. Установка Jekyll


Если коротко, Jekyll это простой генератор статических сайтов, который изначально был разработан для создания блогов и последующего их размещения на GitHub Pages. Идея состоит в разделении контента и его оформления с использованием системы шаблонов Liquid: каталог с текстовыми файлами в формате Markdown или Textile обрабатывается конвертером и рендерером Liquid, а на выходе получается набор объединенных ссылками страниц HTML. Разместить их можно на любом сервере, для этого не потребуется CMS или доступ к СУБД все просто и безопасно.

Поскольку Jekyll представляет собой пакет (гем) Ruby, инсталлировать его несложно. Для этого в системе должен быть установлен Ruby версии не ниже 2.5.0, RubyGems, GCC и Make:

gem install bundler jekyll # 

При необходимости используйте sudo.

Как видите, все очень просто.

Шаг 3. Создание блога


Чтобы создать новый сайт в подкаталоге ./mysite, нужно выполнить команду:

jekyll new mysite

Перейдем в него и посмотрим содержимое

cd mysitels -l




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

bundle exec jekyll serve

Он отслеживает изменения контента и слушает порт 4000 на localhost (http://localhost:4000/) этот вариант может пригодиться, если Jekyll развернут на локальной машине.



В нашем случае стоит сгенерировать сайт и настроить веб-сервер для его просмотра (или выложить файлы на сторонний хостинг):

jekyll build

Созданные файлы находятся в подкаталоге _site каталога mysite.



Мы рассказали далеко не обо всех премудростях Jekyll. Благодаря возможностям верстки кода с подсветкой синтаксиса, больше всего этот генератор контента подходит для создания блогов разработчиков, однако на основе доступных в сети шаблонов с его помощью можно создавать самые разные статические сайты. Есть для Jekyll и плагины, которые позволяют изменить сам процесс генерации HTML. Если нужен контроль версий, файлы с контентом можно разместить в репозитории на GitHub (тогда на VPS придется установить Git).

Самое главное, что для этого пользователю не потребуются дорогостоящие тарифы. Все будет работать даже на той самой 30-рублевой VPS.



Подробнее..

Как я собирал статистику по брутфорсу наших серверов и лечил их

21.09.2020 14:20:44 | Автор: admin

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

Один сервер находился в Лондоне, другой в Цюрихе, один в защищенной сети в M9, два других в дата-центре Rucloud в защищенной и незащищенной сетях. IP адреса каждого из серверов находятся в разных подсетях, каждый IP адрес отличается первым октетом. Если попытаться измерить расстояние скана между IP адресами по формуле:

((Первый октет подсети 1) (Первый октет подсети 2)) * (2^24),

Если сканировать 0.0.0.0/0, атакующему придется пролистать как минимум 771751936 IP адресов, чтобы найти два самых ближайших друг к другу сервера. Вдобавок, каждый из серверов не отвечал на ICMP и каждый IP адрес не использовался никем в течение 3 месяцев, все 5 серверов открыли порты в одно и то же время. Все серверы были подключены к AD.

Разноцветные графики


Начинаем с интересного и заканчиваем значительным.



Начало было хорошим. Первый брутфорсер сел на сервер в Rucloud в первый же час, как порт был открыт. На всех остальных дата-центрах сервер был обнаружен только на второй час.

Как видно на графиках, сила перебора не сильно менялась изо дня в день. А если посмотреть по времени суток? Вот графики. Разные цвета это разные сутки.


График по времени суток дц ZUR1.


График по времени суток в защищенной подсети M9.


График по времени суток в дц LD8.


График по времени суток в защищенной подсети Rucloud.


График по времени суток в Rucloud.

Достаточно скучная картина, можно сказать, что картина не меняется в зависимости от времени суток.

Посмотрим на эти же графики по времени суток, но уже суммарно по всем дата-центрам.


График по времени суток с накоплением.


График по времени суток.

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


Статистика неудачных попыток входа по каждому адресу по одной незащищенной подсети Rucloud.

Всего, в переборе за целую неделю на одной из незащищенных подсетей Rucloud поучаствовали 89 IP адресов. 10 IP адресов набили 50% из 114809 попыток.


Статистика неудачных попыток входа по каждому адресу по всем дата-центрам.

Этот же самый блин, но только со статистикой по всем дата-центрам. 50% всей статистики набили 15 IP адресов. Попыток по всем пяти серверам было более полумиллиона. А насколько разными были атакующие?



По всем сетям было замечено 143 IP адресов и лишь 29 IP адресов было замечено на всех 5 серверах. Меньше половины из всех атакующих брутили 2 или более сервера. Значит, расстояние сканирования между IP адресами имеет значение. Значит, данные об открытых портах атакующие получали с помощью nmap, сканируя IP адреса один за другим.

Считаем ботнеты


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

Предположим, что это все разные ботнеты с разными словарями, тогда, я насчитал N ботнетов. Вот словари каждого из них:

admin, administrator, administrador, administrateur, admin, administrator, administrador, administrateur, ADMIN, USER, USER1, TEST, TEST1, ADMINISTRATOR, USER1, USER2, USER3, USER4, USER5, USER6, USER7, USER8, USER9, HP, ADMIN, USER, PC, DENTAL

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

1, 12, 123, 1234, 12345, 13, 14, 15, 19, 1C, CAMERA, СAMERA, ADMIN, USERL8, GVC, ADMINISTRATEUR, IPAD3, USR_TERMINAL, JEREMY, ADMINISTRATOR, ADM, ALYSSA, ADMINISTRATOR, ATELIER, CAMERA, СAMERA, ADMIN, USERL8, GVC, ADMINISTRATEUR, USR_TERMINAL, JEREMY, IPAD3, USR_TERMINAL, JEREMY, ADMINISTRATOR, ADMIN, ADM, SERGEY, OLEG, IRINA, NATASHA, SYSTEM, SERVICE, GVC, ADMINISTRATEUR, IPAD3, USR_TERMINAL, JEREMY, ADMINISTRATOR, ADMIN, ADM, SERGEY, OLEG, IRINA, NATASHA и так далее, включая даже китайские логины.

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

SHENZHEN, TIANJIN, MANDARIN, CHONGQING, SHENYANG, XIAN, CONS, CHINA, TECHNOLOGY, ISPADMIN, BEIJING, SHANGHAI

Так же были единичные IP адреса пытающиеся перебирать эти логины. Вероятно, просто дети играются:

USR1CV8, ADMINISTRATOR
ADMI, NIMDA, ADMS, ADMINS

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

Специалисты по ИБ знают о BloodHound, о ней знаю и хакеры. Если мы оставим AD в дефолтном её состоянии, то можно похитить имя домена, имя компьютера, даже хэши паролей юзеров. На хабре уже писали о векторах атаки на AD и об этой тулзе. Я рекоменду к прочтению этот блестящий материал.

Кстати, первая атака с применением имени сервера и домена началась через 13 часов после открытия портов, но взломщик быстро отстал, попытавшись ворваться всего 138 раз. Вторая такая атака с этим же словарем повторилась через 3 дня, но тоже долго не продлилась.

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

А это проблема?


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

Подозрения на инфраструктуру быстро исчезли, когда наши немногочисленные клиенты на Windows Server 2008, те не могли зайти на RDP в принципе. Посмотрев в журнал безопасности, мы фиксировали рекордные показатели атак, более 36 тысяч попыток за 24 часа.

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

Генез проблемы до конца неясен. Либо RDP кладется всей сворой, либо каким-то одним атакующим. Воспроизвести дисконнекты и зависание картинки с помощью скрипта и mstsc.exe не удалось.

То ли брутфорс превращается в DDoS, толи у какого-то из атакующих как-то по-особому реализована брутилка, что вызывает и проблемы. Единственное что ясно, что время разрыва соединение совпадает с неудачными попытками входа в систему.

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


Источник: Kaspersky

Решение?


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

Модули работают на Windows Powershell 5.1 и Powershell Core 7. Ссылка на гитхаб проекта находится тут. Теперь взглянем на функции.

Protect-Bruteforce


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



Unprotect-Bruteforce


Сбрасывает RemoteAddress для дефолтных правил брандмауэра.



Stop-Bruteforce


Просматривает журнал событий на предмет неудачных входов и блокирует IP адреса из списка отдельным правилом Stop-Bruteforce.



Get-Bruteforce


Возвращает массив объектов статистики по каждому IP адресу. Именно этой функцией собиралась статистика для графиков выше.



Опрос


Мы в RUVDS считаем, что операционная система должна доставляться пользователю в предельно неизмененном состоянии. Мы думаем, что в идеальном мире, операционная система должна предоставляться так, какой она была в своем стоковом состоянии при первом запуске. Но ведь функции, такие как генерация паролей из ЛК, не только упрощают жизнь, просто необходимы многим нашим клиентам. Хотим знать ваше мнение о подобного рода quality of life штуках. Голосуйте и комментируйте.




Подробнее..

Бесплатная бухгалтерия для одинокого ИП миф или реальность?

23.09.2020 14:17:26 | Автор: admin


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

Какие задачи возникают?


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

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

  • Выставление счетов клиентам и ведение первичной бухгалтерской документации (договоры, акты и т.д.);
  • Финансовый учет и взаимодействие с банками (получение выписок и формирование платежных документов);
  • Правильное совмещение различных режимов налогообложения, например, в случае использования патентов;
  • ККМ и работа с кассой, если в бизнесе вращаются наличные деньги и/или принимаются платежи (наличными и по карте) от физических лиц;
  • Движение товаров и склад;
  • Своевременная уплата налогов и взносов за себя с правильным заполнением всех реквизитов в платежных документах;
  • Ведение КУДиР;
  • Формирование и сдача декларации по УСН (раз в год);
  • Сдача форм в Росстат (по требованию).

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

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

Какие решения предлагает рынок?


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

  • Коробочная версия 1С: Предприятия для малого бизнеса (конфигурация Упрощенка и вот это все). Стоит продукт на первый взгляд недорого, но купить и забыть это не про 1С, потому что на низком старте уже стоит франчайзи с доильным аппаратом в виде договора ИТС. Одинокому ИП он вроде бы не нужен, но иначе не получишь обновлений через портал. За локальную версию 1С платить придется регулярно, смиритесь;
  • Облачная бухгалтерия 1С: ФРЕШ БизнесСтарт или другая конфигурация. Хороший вариант, если у вас есть наемные работники и выделенный (приходящий) бухгалтер, но для одинокого ИП он может оказаться чрезмерным. Из недостатков стоит отметить только необходимость хранить свои данные в чужом облаке и регулярно вносить абонентскую плату, размер которой зависит от набора используемых услуг;
  • Облачная бухгалтерия банка или специализированный бухгалтерский онлайн-сервис. Отдельный сервис закрывает все задачи ИП, но стоит довольно дорого. Предлагаемые банками решения можно получить вместе с расчетно-кассовым обслуживанием, но только на платных тарифах. Как правило возможности бухгалтерии от кредитной организации ограничены, хотя для мелких ИП их будет достаточно. С другой стороны, на рынке появились неплохие бесплатные тарифы на РКО (без бухгалтерии), поэтому отдавать деньги банку за обслуживание счета нет никакой нужды;
  • 1С: ПРЕДПРИЯТИЕ в аренду на виртуальном сервере RuVDS. Этот вариант объединяет преимущества первых двух без их недостатков. Данные будут храниться на VDS клиента, а не в общем облаке. При этом работа пользователей с программой не отличается от локальной, а договор на ИТС для получения обновлений заключать не требуется. Цена довольно демократичная, но если ИП работает сам-один, она может показаться высокой. При наличии наемников, бухгалтеров и сложных бизнес-процессов это лучшее на наш взгляд предложение;
  • Бесплатная версия 1С: Предприятия для iOS/iPadOS и Android. Мобильное приложение решает практически все задачи мелкого ИП, но не умеет интегрироваться с ККМ и системами ЭДО. К тому же учет ведется только на смартфоне или планшете. За продвинутые возможности (включая работу на десктопе через браузер) все равно придется платить, приобретая подписку на облачные решения 1С (все тот же БизнесСтарт);
  • Свободно распространяемые бухгалтерские программы и системы ERP. Сообществу разработчиков СПО похвастать особо нечем. Был когда-то отечественный продукт Ананас, но его поддержка давно прекращена. Иностранные системы сложны в настройке и не учитывают в полной мере специфику российского бухучета.
  • Условно-бесплатные отечественные программные продукты для Windows. Если возможностей мобильной версии 1С: Предприятия вам не хватает, а за настольную или облачную бухгалтерию платить не хочется, стоит остановиться на этом варианте. Учет и отчетность у мелкого одинокого ИП не особенно сложны, поэтому альтернативные продукты заслуживают внимания.

Как сэкономить?


Конкурентов у 1С: Предприятия довольно много. Есть различные системы ERP для крупных компаний, а также простые решения для малого бизнеса. Последние чаще всего условно-бесплатны: покупать придется дополнительные возможности и/или поддержку. Особенно радует, что эти программы можно не только скачать и установить, но и обновлять даром. Вот далеко не полный список альтернатив 1С: ИП УСН 2, Инфо-предприятие, Бизнес Пак и Своя Технология. В смысле функциональности они уступают решениям лидера рынка, но работать с альтернативными программами людям без бухгалтерского образования проще. Для теста мы выбрали первые два варианта за оптимальное сочетание возможностей бесплатной версии, удобства использования, частоты обновлений и стоимости коммерческих лицензий.

Как развернуть?


Условно-бесплатные бухгалтерские программы не особо требовательны к ресурсам и работают даже на Windows XP. Развернуть их можно на локальном компьютере или недорогом виртуальном сервере. Преимущества второго варианта в отсутствии необходимости приобретать и обслуживать оборудование и возможности получить доступ к системе из любой точки планеты, где есть интернет. Используя VDS, нетрудно организовать и многопользовательскую удаленную работу, если вдруг возникнет такая потребность. Дорогие тарифы для этого не требуются: мы проводили все тесты на машине с минимальной конфигурацией и Windows Server 2012.



Дальше нужно скачать выбранный дистрибутив и установить его на виртуальный сервер.

Начнем с ИП УСН 2. Для работы программе потребуется также .NET Framework 2.0 или выше. При годовом обороте до 1 млн. рублей ее можно использовать бесплатно, а при более высоком лицензия стоит 1000 рублей в год. Пользователю доступны функции финансового учета (банковские и кассовые операции), работа с первичными документами, автоматический расчет налогов и взносов, подготовка налоговой отчетности и другие возможности, включая интеграцию с системами ЭДО и банк-клиентом, конструктор договоров и разнообразные справочники. Поддерживается только режим УСН 6% без наемных работников. После запуска программа регулярно проверяет наличие обновлений на сайте разработчика.



Возможности бухгалтерии Инфо-Предприятия гораздо шире, к тому же разработчик предлагает и другие продукты, а в бесплатную поставку входит налоговый учет для разных режимов налогообложения (ОРН, УСН, УСН на основе патента, ЕСХН, ЕНВД), работа с первичными документами, финансовый учет, взаимодействие с банками и касса. Также бесплатно доступен модуль Зарплата, кадровый учет, внутренние отчеты и многомерная аналитика. В бесплатной версии нет возможностей многопользовательской работы, программирования на встроенном языке, а также некоторых дополнительных функций и интеграции с другими продуктами разработчика для комплексной автоматизации предприятия. Детальное сравнение версий доступно на сайте.



Мы посмотрели одну простую программу для ИП на УСН 6% без сотрудников и одну продвинутую разработку, подходящую и для более крупного бизнеса. Вывод прост: в России есть актуальные учетные системы, которыми можно пользоваться бесплатно. Сделаны они неплохо, но чтобы определиться с выбором, предпринимателям лучше развернуть программы самостоятельно. Для тестов рекомендуем использовать наш виртуальный сервер )

Если тема заинтересует читателей блога, мы изучим ее более детально. За кадром осталось немало интересного: интеграция запущенного на VDS бухгалтерского приложения с системами юридически значимого ЭДО, дистанционная сдача отчетности, работа с ККМ и т.д.



Подробнее..

Чем мониторить кластеры на Kubernetes три открытых инструмента один из них в формате игры

13.09.2020 20:11:44 | Автор: admin
Это наша компактная подборка бесплатных инструментов, позволяющих оценить производительность и стабильность контейнеризированных приложений.

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


Фото Ellen Qin Unsplash



Kmoncon


Это система мониторинга подключений нодов в кластере Kubernetes. Её разработал инженер Карл Стони (Karl Stoney), который поддерживает облачную инфраструктуру и контейнеризированные приложения в Auto Trader UK (это одна из крупнейших площадок по продаже подержанных автомобилей в Великобритании).

Kmoncon проверяет подключения по TCP, UDP, а также DNS (тесты проводятся каждые пять секунд). Оценка строится на базе модифицированных метрик Prometheus к стандартным параметрам были добавлены имена нодов и зоны доступности. Инструмент совместим с другими системами мониторинга L7-уровня, такими как Istio Observability или Kube State Metrics. По словам автора, для кластера из 75 нодов система потребляет всего 40 Мбайт оперативной памяти.


/ Скриншот дашборда Kmoncon / GitHub

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



Kube-chaos


Это инструмент для интерактивной проверки надежности кластеров Kubernetes. Он реализован в формате компьютерной игры на движке Unity. Вы управляете виртуальным космическим кораблем и стреляете в светящиеся квадраты, представляющие собой реальные поды. У каждого из них есть определенный объем здоровья. Когда оно заканчивается, игра посылает команду destroy pod через kubectl и удаляет соответствующий под.


/ Геймплей Kube-chaos / GitHub

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

Для установки игры на своем кластере автор предлагает использовать arkade это CLI для Kubernetes, позволяющий развертывать приложения одной командой. Хотя стоит отметить, что проект представляет собой PoC и, вероятно, с ним не стоит работать в продакшн.



Lens


Интегрированная среда разработки (IDE) для Kubernetes, оптимизированная для работы с большим количеством подов (до 25 тыс.). Она умеет визуализировать состояние кластера в реальном времени и строить графики, отражающие задействованные ресурсы (использованы метрики Prometheus).

Lens представляет собой автономное приложение (развертка каких-либо агентов внутри кластера не требуется), которое устанавливается на компьютер с Linux, macOS или Windows. Первую версию инструмента представила компания Kontena, но сегодня его развитием занимается организация Lakend Labs. Она продвигает и поддерживает open source проекты для облачных сред.

Проект относительно молодой, но вокруг него уже сформировалось обширное сообщество. Lens второй по популярности проект на GitHub в соответствующей категории, который имеет 8,2 тыс. звезд.



О чем мы пишем в нашем корпоративном блоге:

Подборка книг о кибербезопасности: как провести пентест и что противопоставить социальной инженерии
Нельзя так просто взять и перепрошить свой гаджет
Какие кабели соединят Африку, Азию и Австралию
Бенчмарки для Linux-серверов



Подробнее..

Как управлять облачной инфраструктурой с помощью Terraform

24.09.2020 10:22:34 | Автор: admin

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

Обо всем подробно и в три этапа:

1. Terraform описание, преимущества и составляющие

Terraform это IaC (Infrastructure-as-Code) инструмент для построения и управления виртуальной инфраструктурой с помощью кода .

В работе с инструментом мы отметили несколько преимуществ:

  • Скорость развертывания новых тенантов (пользовательских виртуальных сред). Обычно, чем больше новых клиентов, тем больше "кликов" требуется сделать сотрудникам технической поддержки для публикации новых ресурсов. С Terraform пользователи могут изменять параметры виртуальных машин (например, автоматически выключать ОС и увеличивать раздел виртуального диска ) без участия технической поддержки и выключения самой машины.

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

  • Возможность описывать большинство популярных облачных платформ. Вы можете использовать инструмент от Amazon и Google Cloud, до частных платформ на базе VMware vCloud Director, предлагающих услуги в рамках IaaS, SaaS и PaaS решений.

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

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

"Террариум" Terraform

Кратко рассказали про преимущества инструмента, теперь разберем его на составляющие

Providers (провайдеры).

В Terraform практически любой тип инфраструктуры можно представить в качестве ресурса. Связь между ресурсами и платформой API обеспечивается providers модулями, которые позволяют создавать ресурсы в рамках определённой платформы, например, Azure или VMware vCloud Director.

В рамках проекта вы можете взаимодействовать с разными провайдерами на разных платформах.

Resources (описание ресурсов).

Описание ресурсов позволяет управлять компонентами платформы, например виртуальными машинами или сетями.

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

Provisioners.

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

Переменные Input и Output.

Input переменные входные переменные для любых типов блоков.

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

States (состояния).

States-файлы хранят информацию о конфигурации ресурсов платформы провайдера. При первом создании платформы никаких сведений о ресурсах нет и перед любой операцией Terraform обновляет состояние с реальной инфраструктурой уже описанных ресурсов.

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

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

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

2. Создание инфраструктуры

Составляющие разобрали, теперь с помощью Terraform мы поэтапно создадим инфраструктуру с тремя виртуальными машинами. Первая с установленным прокси-сервером nginx, вторая с файловым хранилищем на базе Nextcloud и третья с CMS Bitrix.

Писать код и исполнять его мы будем на примере нашего облака на VMware vCloud Director. У нас пользователи получают учётную запись правами Organization Administrator, если вы используете учетную запись с теми же правами в другом облаке VMware, то сможете воспроизвести код из наших примеров. Поехали!

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

mkdir project01

Затем опишем компоненты инфраструктуры. Terraform создаёт связи и обрабатывает файлы на основании описания в файлах. Сами файлы можно именовать исходя из целевого назначения описываемых блоков, например, network.tf - описывает сетевые параметры для инфраструктуры.

Для описания компонентов нашей инфраструктуры, мы создали следующие файлы:

Список файлов.

main.tf - описание параметров для виртуальной среды - виртуальные машины, виртуальные контейнеры;

network.tf - описание параметров виртуальной сети и правил NAT, Firewall;

variables.tf - список переменных, которые используем;

vcd.tfvars - значения переменных проекта для модуля VMware vCloud Director.

Язык конфигурации в Terraform является декларативным и порядок блоков не имеет значения, кроме блоков provisioner, т.к. в этом блоке мы описываем команды для выполнения при подготовке инфраструктуры и они будут выполнятся по порядку.

Структура блоков.

<BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {

# Block body

<IDENTIFIER> = <EXPRESSION> # Argument

}

Для описания блоков используется собственный язык программирования HCL (HashiCorp Configuration Language), возможно описывать инфраструктуру и с помощью JSON. Подробнее о синтаксисе можно прочитать на сайте разработчика.

Конфигурация переменной окружения, variables.tf и vcd.tfvars

Сначала создадим два файла, которые описывают список всех используемых переменных и их значений для модуля VMware vCloud Director. Первым создадим файл variables.tf.

Cодержимое файла variables.tf.

variable "vcdorguser" {

description = "vCD Tenant User"

}

variable "vcdorgpassword" {

description = "vCD Tenant Password"

}

variable "vcdorg" {

description = "vCD Tenant Org"

}

variable "vcdorgvdc" {

description = "vCD Tenant VDC"

}

variable "vcdorg_url" {

description = "vCD Tenant URL"

}

variable "vcdorgmaxretrytimeout" {

default = "60"

}

variable "vcdorgallowunverifiedssl" {

default = "true"

}

variable "vcdorgedgename" {

description = "vCD edge name"

}

variable "vcdorgcatalog" {

description = "vCD public catalog"

}

variable "vcdtemplateoscentos7" {

description = "OS CentOS 7"

default = "CentOS7"

}

variable "vcdorgssdsp" {

description = "Storage Policies"

default = "Gold Storage Policy"

}

variable "vcdorghddsp" {

description = "Storage Policies"

default = "Bronze Storage Policy"

}

variable "vcdedgelocalsubnet" {

description = "Organization Network Subnet"

}

variable "vcdedgeexternalip" {

description = "External public IP"

}

variable "vcdedgelocalipnginx" {}

variable "vcdedgelocalipbitrix" {}

variable "vcdedgelocalC11Cnextcloud" {}

variable "vcdC12Cexternal_network" {}

Значения переменных, которые мы получаем от провайдера.
  • vcd_org_user - имя пользователя с правами Organization Administrator,

  • vcd_org_password - пароль пользователя,

  • vcd_org - название организации,

  • vcd_org_vdc - название виртуального дата-центра,

  • vcd_org_url - API URL,

  • vcd_org_edge_name - название виртуального маршрутизатора,

  • vcd_org_catalog - название каталога с шаблонами виртуальных машин,

  • vcd_edge_external_ip - публичный IP-адрес,

  • vcd_edge_external_network - название внешней сети,

  • vcd_org_hdd_sp - название политики хранения HDD,

  • vcd_org_ssd_sp - название политики хранения SSD.

И вводим свои переменные:

  • vcdedgelocalipnginx - IP-адрес виртуальной машины с NGINX,

  • vcdedgelocalipbitrix - IP-адрес виртуальной машины с 1С: Битрикс,

  • vcdedgelocalipnextcloud - IP-адрес виртуальной машины с Nextcloud.

Вторым файлом создаем и указываем переменные для модуля VMware vCloud Director в файле vcd.tfvars: Напомним, что в нашем примере мы используем собственное облако mClouds, если вы работаете с другим провайдером уточните значения у него.

Содержимое файла vcd.tfvars.

vcdorgurl = "https://vcloud.mclouds.ru/api"

vcdorguser = "orgadmin"

vcdorgpassword = "*"

vcd = "org"

vcdorgvdc = "orgvdc"

vcdorgmaxretrytimeout = 60

vcdorgallowunverifiedssl = true

vcdorgcatalog = "Templates"

vcdtemplateos_centos7 = "CentOS7"

vcdorgssdsp = "Gold Storage Policy"

vcdorghddsp = "Bronze Storage Policy"

vcdorgedgename = "MCLOUDS-EDGE"

vcdedgeexternalip = "185.17.66.1"

vcdedgelocalsubnet = "192.168.110.0/24"

vcdedgelocalipnginx = "192.168.110.1"

vcdedgelocalipbitrix = "192.168.110.10"

vcdedgelocalipnextcloud = "192.168.110.11"

vcdedgeexternal_network = "NET-185-17-66-0"

Сетевая конфигурация, network.tf.

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

Схема сети для создаваемой Terraform платформыСхема сети для создаваемой Terraform платформы

Создаем виртуальную организационную сеть с названием net_lan01, шлюзом по умолчанию: 192.168.110.254, а также с адресным пространством: 192.168.110.0/24.

Описываем виртуальную сеть.

resource "vcdnetworkrouted" "net" {

name = "netlan01"

edgegateway = var.vcdorgedgename

gateway = "192.168.110.254"

dns1 = "1.1.1.1"

dns2 = "8.8.8.8"

staticippool {

startaddress = "192.168.110.1"

end_address = "192.168.110.253"

}

}

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

Описываем правила для доступа VM в интернет.

resource "vcdnsxvfirewallrule" "fwinternetaccess" {

edgegateway = var.vcdorgedgename

name = "Internet Access"

source {

gatewayinterfaces = ["internal"]

}

destination {

gatewayinterfaces = ["external"]

}

service {

protocol = "any"

}

dependson = [vcdnetworkrouted.net]

}

Установив зависимость, что после обработки блока vcdnetworkrouted.net мы приступаем к конфигурации блока vcdnsxvfirewallrule, с помощью dependson. Используем эту опцию, так как некоторые зависимости могут быть распознаны неявно в конфигурации.

Далее создадим правила разрешающее доступ к портам из внешней сети и указываем наш IP-адрес для подключения по SSH к серверам. Любой пользователь сети Интернет имеет доступ к портам 80 и 443 на веб-сервере и пользователь с IP-адресом 90.1.15.1 имеет доступ к портам SSH виртуальных серверов.

Разрешаем доступ к портам из внешней сети.

resource "vcdnsxvfirewallrule" "fwnatports" {

edgegateway = var.vcdorgedgename

name = "HTTPs Access"

source {

gatewayinterfaces = ["external"]

}

destination {

gateway_interfaces = ["internal"]

}

service {

protocol = "tcp"

port = "80"

}

service {

protocol = "tcp"

port = "443"

}

dependson = [vcdnetworkrouted.net]

}

resource "vcdnsxvfirewallrule" "fwnatadminports" {

edgegateway = var.vcdorgedgename

name = "Admin Access"

source {

ipaddresses = [ "90.1.15.1" ]

}

destination {

gatewayinterfaces = ["internal"]

}

service {

protocol = "tcp"

port = "58301"

}

service {

protocol = "tcp"

port = "58302"

}

service {

protocol = "tcp"

port = "58303"

}

depends_on = [vcdnetworkrouted.net]

}

Создаём правила Source NAT для доступа в сеть Интернет из облачной локальной сети:

Описываем правила Source NAT.

resource "vcdnsxvsnat" "snatlocal" {

edgegateway = var.vcdorgedgename

networktype = "ext"

networkname = var.vcdedgeexternalnetwork

originaladdress = var.vcdedgelocalsubnet

translatedaddress = var.vcdedgeexternalip

dependson = [vcdnetwork_routed.net]

}

И в завершении конфигурации сетевого блока добавляем правила Destination NAT для доступа к сервисам из внешней сети:

Добавляем правила Destination NAT.

resource "vcd_nsxv_dnat" "dnat_tcp_nginx_https" { edge_gateway = var.vcd_org_edge_name network_name = var.vcd_edge_external_network network_type = "ext"

description = "NGINX HTTPs"

original_address = var.vcd_edge_external_ip original_port = 443

translated_address = var.vcd_edge_local_ip_nginx translated_port= 443 protocol = "tcp"

depends_on = [vcd_network_routed.net]}resource "vcd_nsxv_dnat" "dnat_tcp_nginx_http" { edge_gateway = var.vcd_org_edge_name network_name = var.vcd_edge_external_network network_type = "ext"

description = "NGINX HTTP"

original_address = var.vcd_edge_external_ip original_port = 80

translated_address = var.vcd_edge_local_ip_nginx translated_port= 80 protocol = "tcp"

depends_on = [vcd_network_routed.net]

}

Добавляем правило NAT для трансляции портов к SSH-серверу под Nginx.

resource "vcd_nsxv_dnat" "dnat_tcp-nginx_ssh" { edge_gateway = var.vcd_org_edge_name network_name = var.vcd_edge_external_network network_type = "ext"

description = "SSH NGINX"

original_address = var.vcd_edge_external_ip original_port = 58301

translated_address = var.vcd_edge_local_ip_nginx translated_port= 22 protocol = "tcp"

depends_on = [vcd_network_routed.net]

}

Добавляем правило NAT для трансляции портов к SSH-серверу с 1С-Битрикс.

resource "vcd_nsxv_dnat" "dnat_tcp_bitrix_ssh" { edge_gateway = var.vcd_org_edge_name network_name = var.vcd_edge_external_network network_type = "ext"

description = "SSH Bitrix"

original_address = var.vcd_edge_external_ip original_port = 58302

translated_address = var.vcd_edge_local_ip_bitrix translated_port= 22 protocol = "tcp"

depends_on = [vcd_network_routed.net]

}

Добавляем правило NAT для трансляции портов к SSH-серверу с Nextcloud.

resource "vcd_nsxv_dnat" "dnat_tcp_nextcloud_ssh" { edge_gateway = var.vcd_org_edge_name network_name = var.vcd_edge_external_network network_type = "ext"

description = "SSH Nextcloud"

original_address = var.vcd_edge_external_ip original_port = 58303 translated_address = var.vcd_edge_local_ip_nextcloud translated_port= 22 protocol = "tcp"

depends_on = [vcd_network_routed.net]

}

Конфигурация виртуальной среды main.tf

Как мы и планировали в начале статьи, создадим три виртуальные машины. Они будут подготовлены с помощью "Guest Customization". Сетевые параметры пропишем согласно указанным нами настройками, а пароль от пользователя генерируется автоматически.

Опишем vApp в котором будут находится виртуальные машины и их конфигурацию.

Конфигурация виртуальных машинКонфигурация виртуальных машин

Создадим контейнер vApp. Чтобы мы могли сразу же подключить vApp и ВМ к виртуальной сети также добавляем параметр depends_on:

Создаем контейнер

resource "vcd_vapp" "vapp" { name = "web" power_on = "true" depends_on = [vcd_network_routed.net]

}

Создадим виртуальную машину с описанием

resource "vcd_vapp_vm" "nginx" {

vapp_name = vcd_vapp.vapp.name

name = "nginx"

catalog_name = var.vcd_org_catalog

template_name = var.vcd_template_os_centos7

storage_profile = var.vcd_org_ssd_sp

memory = 8192

cpus = 1

cpu_cores = 1

network {

type = "org"

name = vcd_network_routed.net.name

is_primary = true

adapter_type = "VMXNET3"

ip_allocation_mode = "MANUAL"

ip = var.vcd_edge_local_ip_nginx

}

override_template_disk {

bus_type = "paravirtual"

size_in_mb = "32768"

bus_number = 0

unit_number = 0

storage_profile = var.vcd_org_ssd_sp

}

}

Основные параметры в описании VM:

  • name - имя виртуальной машины,

  • vappname - название vApp в который добавить новую ВМ,

  • catalogname / templatename - название каталога и название шаблона виртуальной машины,

  • storageprofile - политика хранения по умолчанию.

Параметры блока network:

  • type - тип подключаемой сети,

  • name - к какой виртуальной сети подключить ВМ,

  • isprimary - основной сетевой адаптер,

  • ipallocation_mode - режим выделения адреса MANUAL / DHCP / POOL,

  • ip - IP-адрес для виртуальной машины, укажем вручную.

Блок override_template_disk:

  • sizeinmb - размер boot-диска для виртуальной машины

  • storage_profile - политика хранения для диска

Создадим вторую VM с описанием файлового хранилища Nextcloud

resource "vcd_vapp_vm" "nextcloud" {

vapp_name = vcd_vapp.vapp.name

name = "nextcloud"

catalog_name = var.vcd_org_catalog

template_name = var.vcd_template_os_centos7

storage_profile = var.vcd_org_ssd_sp

memory = 8192

cpus = 1

cpu_cores = 1

network {

type = "org"

name = vcd_network_routed.net.name

is_primary = true

adapter_type = "VMXNET3"

ip_allocation_mode = "MANUAL"

ip = var.vcd_edge_local_ip_nextcloud

}

override_template_disk {

bus_type = "paravirtual"

size_in_mb = "32768"

bus_number = 0

unit_number = 0

storage_profile = var.vcd_org_ssd_sp

}

}

resource "vcd_vm_internal_disk" "disk1" {

vapp_name = vcd_vapp.vapp.name

vm_name = "nextcloud"

bus_type = "paravirtual"

size_in_mb = "102400"

bus_number = 0

unit_number = 1

storage_profile = var.vcd_org_hdd_sp

allow_vm_reboot = true

depends_on = [ vcd_vapp_vm.nextcloud ]

}

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

Пояснения по блоку vcdvminternaldisk:

  • bustype - тип дискового контроллера

  • sizeinmb - размер диска

  • busnumber / unitnumber - место подключения в адаптере

  • storage_profile - политика хранения для диска

Опишем последнюю VM на Битрикс

resource "vcd_vapp_vm" "bitrix" {

vapp_name = vcd_vapp.vapp.name

name = "bitrix"

catalog_name = var.vcd_org_catalog

template_name = var.vcd_template_os_centos7

storage_profile = var.vcd_org_ssd_sp

memory = 8192

cpus = 1

cpu_cores = 1

network {

type = "org"

name = vcd_network_routed.net.name

is_primary = true

adapter_type = "VMXNET3"

ip_allocation_mode = "MANUAL"

ip = var.vcd_edge_local_ip_bitrix

}

override_template_disk {

bus_type = "paravirtual"

size_in_mb = "81920"

bus_number = 0

unit_number = 0

storage_profile = var.vcd_org_ssd_sp

}

}

Обновление ОС и установка дополнительных скриптов

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

Рассмотрим как обновить ОС и запустить установочный скрипт CMS Bitrix с помощью provisioner блока.

Сначала выполним установку пакетов обновления CentOS.

resource "null_resource" "nginx_update_install" {

provisioner "remote-exec" {

connection {

type = "ssh"

user = "root"

password = vcd_vapp_vm.nginx.customization[0].admin_password

host = var.vcd_edge_external_ip

port = "58301"

timeout = "30s"

}

inline = [

"yum -y update && yum -y upgrade",

"yum -y install wget nano epel-release net-tools unzip zip" ]

}

}

}

Обозначение составляющих:

  • provisioner "remote-exec" - подключаем блок удаленного "провижининга"

  • В блоке connection описываем тип и параметры для подключения:

  • type - протокол, в нашем случае SSH;

  • user - имя пользователя;

  • password - пароль пользователя. В нашем случае указываем на параметр vcdvappvm.nginx.customization[0].admin_password, который хранит сгенерированный пароль от пользователя системы.

  • host - внешний IP-адрес для подключения;

  • port - порт для подключения, который ранее указывали в настройках DNAT;

  • inline - перечисляем список команд, которые будут вводится. Команды будут введены по порядку, как и указано в этой секции.

Как пример, дополнительно выполним скрипт установки 1С-Битрикс. Вывод результата выполнения скрипта будет доступен во время выполнения плана. Для установки скрипта, сначала опишем блок:

Опишем установку 1С-Битрикс.

provisioner "file" {

source = "prepare.sh"

destination = "/tmp/prepare.sh"

connection {

type = "ssh"

user = "root"

password = vcd_vapp_vm.nginx.customization[0].admin_password

host = var.vcd_edge_external_ip

port = "58301"

timeout = "30s"

}

}

provisioner "remote-exec" {

inline = [

"chmod +x /tmp/prepare.sh", "./tmp/prepare.sh"

]

}

И сразу же опишем обновление Битрикс.

Пример провижининга 1С-Битрикс.

resource "null_resource" "install_update_bitrix" {

provisioner "remote-exec" {

connection {

type = "ssh"

user = "root"

password = vcd_vapp_vm.bitrix.customization[0].admin_password

host = var.vcd_edge_external_ip

port = "58302"

timeout = "60s"

}

inline = [

"yum -y update && yum -y upgrade",

"yum -y install wget nano epel-release net-tools unzip zip",

"wget http://repos.1c-bitrix.ru/yum/bitrix-env.sh -O /tmp/bitrix-env.sh",

"chmod +x /tmp/bitrix-env.sh",

"/tmp/bitrix-env.sh"

]

}

}

Важно! Скрипт может не сработать, если не отключить заранее SELinux! Если вам требуется подробная статья по установке и настройке CMS 1С-Битрикс с помощью bitrix-env.sh, оо вы можете воспользоваться нашей статьей в блоге на сайте.

3. Инициализация инфраструктуры

Инициализация модулей и плагиновИнициализация модулей и плагинов

Для работы мы используем простой джентельменский набор: лэптоп с ОС Windows 10 и дистрибутив с официального сайта terraform.io. Распакуем и проинициализируем с помощью команды: terraform.exe init

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

  1. Выполняем команду - terraform plan -var-file=vcd.tfvars.

  2. Получаем результат - Plan: 16 to add, 0 to change, 0 to destroy. То есть по этому плану будет создано 16 ресурсов.

  3. Запускаем план по команде - terraform.exe apply -var-file=vcd.tfvars.

Виртуальные машины будут созданы, а затем выполняются перечисленные нами пакеты в рамках секции provisioner ОС будет обновлена и установится CMS Bitrix.

Получение данных для подключения

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

output "nginxpassword" {

value = vcdvappvm.nginx.customization[0].adminpassword

}

И следующий вывод сообщает нам пароль от созданной виртуальной машины:

Outputs: nginx_password = F#4u8!!N

В итоге мы получаем доступ к виртуальным машинам с обновлённой операционной системой и предустановленными пакетами для нашей дальнейшей работы. Все готово!

Но что если у вас уже есть существующая инфраструктура?

3.1. Работа Terraform с уже существующей инфраструктурой

Всё просто, вы можете импортировать текущие виртуальные машины и их vApp контейнеры с помощью команды import.

Опишем ресурс vAPP и виртуальную машину.

resource "vcd_vapp" "Monitoring" {

name = "Monitoring"

org = "mClouds"

vdc = "mClouds"

}

resource "vcd_vapp_vm" "Zabbix" {

name = "Zabbix"

org = "mClouds"

vdc = "mClouds"

vapp = "Monitoring"

}

Следующий шаг, это выполнить импорт свойств ресурсов vApp в формате vcdvapp.<vApp> <org>.<orgvdc>.<vApp>, где:

  • vApp - имя vApp;

  • org - название организации;

  • org_vdc - название виртуального дата-центра.

Импорт свойств ресурса vAPPИмпорт свойств ресурса vAPP

Выполним импорт свойств ресурсов VM в формате: vcdvappvm.<VM> <org>.<orgvdc>.<vApp>.<VM>, в котором:

  • VM - имя VM;

  • vApp - имя vApp;

  • org - название организации;

  • orgvdc - название виртуального дата-центра.

Импорт прошел успешно

C:\Users\Mikhail\Desktop\terraform>terraform import vcd_vapp_vm.Zabbix mClouds.mClouds.Monitoring.Zabbix

vcd_vapp_vm.Zabbix: Importing from ID "mClouds.mClouds.Monitoring.Zabbix"...

vcd_vapp_vm.Zabbix: Import prepared!

Prepared vcd_vapp_vm for import

vcd_vapp_vm.Zabbix: Refreshing state... [id=urn:vcloud:vm:778f4a89-1c8d-45b9-9d94-0472a71c4d1f]

Import successful!

The resources that were imported are shown above. These resources are now inyour Terraform state and will henceforth be managed by Terraform.

Теперь мы можем посмотреть на новый импортированный ресурс:

Импортированный ресурс

> terraform show

...

# vcd_vapp.Monitoring:

resource "vcd_vapp" "Monitoring" {

guest_properties = {}

href = "https://vcloud.mclouds.ru/api/vApp/vapp-fe5db285-a4af-47c4-93e8-55df92f006ec"

id = "urn:vcloud:vapp:fe5db285-a4af-47c4-93e8-55df92f006ec"

ip = "allocated"

metadata = {}

name = "Monitoring"

org = "mClouds"

status = 4

status_text = "POWERED_ON"

vdc = "mClouds"

}

# vcd_vapp_vm.Zabbix:

resource "vcd_vapp_vm" "Zabbix" {

computer_name = "Zabbix"

cpu_cores = 1

cpus = 2

expose_hardware_virtualization = false

guest_properties = {}

hardware_version = "vmx-14"

href = "https://vcloud.mclouds.ru/api/vApp/vm-778f4a89-1c8d-45b9-9d94-0472a71c4d1f"

id = "urn:vcloud:vm:778f4a89-1c8d-45b9-9d94-0472a71c4d1f"

internal_disk = [

{

bus_number = 0

bus_type = "paravirtual"

disk_id = "2000"

iops = 0

size_in_mb = 122880

storage_profile = "Gold Storage Policy"

thin_provisioned = true

unit_number = 0

},

]

memory = 8192

metadata = {}

name = "Zabbix"

org = "mClouds"

os_type = "centos8_64Guest"

storage_profile = "Gold Storage Policy"

vapp_name = "Monitoring"

vdc = "mClouds"

customization {

allow_local_admin_password = true

auto_generate_password = true

change_sid = false

enabled = false

force = false

join_domain = false

join_org_domain = false

must_change_password_on_first_login = false

number_of_auto_logons = 0

}

network {

adapter_type = "VMXNET3"

ip_allocation_mode = "DHCP"

is_primary = true

mac = "00:50:56:07:01:b1"

name = "MCLOUDS-LAN01"

type = "org"

}

}

Теперь точно готово - мы закончили с последним моментом (импорт в существующую инфраструктуру) ирассмотрели все основные моменты работы с Terraform.

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

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

Подробнее..

Дружим ELK и Exchange. Часть 2

24.09.2020 18:11:15 | Автор: admin


Я продолжаю свой рассказ о том, как подружить Exchange и ELK (начало тут). Напомню, что эта комбинация способна без колебаний обрабатывать очень большое количество логов. На это раз мы поговорим о том, как наладить работу Exchange с компонентами Logstash и Kibana.

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

Установка


Состоит из двух этапов:
Установка и настройка пакета OpenJDK.
Установка и настройка пакета Logstash.

Установка и настройка пакета OpenJDK
Пакет OpenJDK необходимо скачать и распаковать в определённую директорию. Затем путь до этой директории необходимо внести в переменные $env:Path и $env:JAVA_HOME операционной системы Windows:



Проверим версию Java:

PS C:\> java -versionopenjdk version "13.0.1" 2019-10-15OpenJDK Runtime Environment (build 13.0.1+9)OpenJDK 64-Bit Server VM (build 13.0.1+9, mixed mode, sharing)

Установка и настройка пакета Logstash


Файл-архив с дистрибутивом Logstash скачайте отсюда. Архив нужно распаковать в корень диска. Распаковывать в папку C:\Program Files не стоит, Logstash откажется нормально запускаться. Затем необходимо внести в файл jvm.options правки, отвечающие за выделение оперативной памяти для процесса Java. Рекомендую указать половину оперативной памяти сервера. Если у него на борту 16 Гб оперативки, то ключи по умолчанию:

-Xms1g-Xmx1g

необходимо заменить на:

-Xms8g-Xmx8g

Кроме этого, целесообразно закомментировать строку -XX:+UseConcMarkSweepGC. Подробнее об этом тут. Следующий шаг создание конфигурации по умолчанию в файле logstash.conf:

input { stdin{}} filter {} output { stdout { codec => "rubydebug" }}

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

PS C:\...\bin> .\logstash.bat -f .\logstash.conf...[2019-12-19T11:15:27,769][INFO ][logstash.javapipeline    ][main] Pipeline started {"pipeline.id"=>"main"}The stdin plugin is now waiting for input:[2019-12-19T11:15:27,847][INFO ][logstash.agent           ] Pipelines running {:count=>1, :running_pipelines=>[:main], :non_running_pipelines=>[]}[2019-12-19T11:15:28,113][INFO ][logstash.agent           ] Successfully started Logstash API endpoint {:port=>9600}

Logstash успешно запустился на порту 9600.

Финальный шаг установки: запуск Logstash в виде сервиса Windows. Это можно сделать, например, с помощью пакета NSSM:

PS C:\...\bin> .\nssm.exe install logstashService "logstash" installed successfully!

Отказоустойчивость


Сохранность логов при передаче с исходного сервера обеспечивается механизмом Persistent Queues.

Как работает


Схема расположения очередей в процессе обработки логов: input queue filter + output.

Плагин input получает данные от источника логов, записывает их в очередь и отправляет источнику подтверждение получения данных.

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

Настройка


Регулируется ключами в файле C:\Logstash\config\logstash.yml:

queue.type: (возможные значения persisted и memory (default)).
path.queue: (путь до папки с файлами очередей, которые по умолчанию хранятся в C:\Logstash\queue).
queue.page_capacity: (максимальный размер страницы очереди, значение по умолчанию 64mb).
queue.drain: (true/false включает/выключает остановку обработки очереди перед выключением Logstash. Не рекомендую включать, потому что это прямо скажется на скорости выключения сервера).
queue.max_events: (максимально число событий в очереди, по умолчанию 0 (не ограничено)).
queue.max_bytes: (максимальный размер очереди в байтах, по умолчанию 1024mb (1gb)).

Если настроены queue.max_events и queue.max_bytes, то сообщения перестают приниматься в очередь при достижении значения любой из этих настроек. Подробнее про Persistent Queues рассказано тут.

Пример части logstash.yml, отвечающей за настройку очереди:

queue.type: persistedqueue.max_bytes: 10gb

Настройка


Конфигурация Logstash обычно состоит из трёх частей, отвечающих за разные фазы обработки входящий логов: приём (секция input), парсинг (секция filter) и отправка в Elastic (секция output). Ниже мы подробнее рассмотрим каждую из них.

Input


Входящий поток с сырыми логами принимаем от агентов filebeat. Именно этот плагин мы и указываем в секции input:

input {  beats {    port => 5044  }}

После такой настройки Logstash начинает прослушивать порт 5044, и при получении логов обрабатывает их согласно настройкам секции filter. При необходимости можно канал получения логов от filebit завернуть в SSL. Подробнее о настройках плагина beats написано тут.

Filter


Все интересные для обработки текстовые логи, которые генерирует Exchange, имеют csv-формат с описанными в самом файле логов полями. Для парсинга csv-записей Logstash предлагает нам три плагина: dissect, csv и grok. Первый самый быстрый, но справляется с парсингом только самых простых логов.
Например, следующую запись он разобьёт на две (из-за наличия внутри поля запятой), из-за чего лог будет разобран неправильно:

,"MDB:GUID1, Mailbox:GUID2, Event:526545791, MessageClass:IPM.Note, CreationTime:2020-05-15T12:01:56.457Z, ClientType:MOMT, SubmissionAssistant:MailboxTransportSubmissionEmailAssistant",

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

filter {  if "IIS" in [tags] {    dissect {      mapping => {        "message" => "%{date} %{time} %{s-ip} %{cs-method} %{cs-uri-stem} %{cs-uri-query} %{s-port} %{cs-username} %{c-ip} %{cs(User-Agent)} %{cs(Referer)} %{sc-status} %{sc-substatus} %{sc-win32-status} %{time-taken}"      }      remove_field => ["message"]      add_field => { "application" => "exchange" }    }  }} 

Конфигурация Logstash позволяет использовать условные операторы, поэтому мы в плагин dissect можем направить только логи, которые были помечены filebeat тэгом IIS. Внутри плагина мы сопоставляем значения полей с их названиями, удаляем исходное поле message, которое содержало запись из лога, и можем добавить произвольное поле, которое будет, например, содержать имя приложения из которого мы собираем логи.

В случае с логами трэкинга лучше использовать плагин csv, он умеет корректно обрабатывать сложные поля:

filter {  if "Tracking" in [tags] {    csv {      columns => ["date-time","client-ip","client-hostname","server-ip","server-hostname","source-context","connector-id","source","event-id","internal-message-id","message-id","network-message-id","recipient-address","recipient-status","total-bytes","recipient-count","related-recipient-address","reference","message-subject","sender-address","return-path","message-info","directionality","tenant-id","original-client-ip","original-server-ip","custom-data","transport-traffic-type","log-id","schema-version"]      remove_field => ["message", "tenant-id", "schema-version"]      add_field => { "application" => "exchange" }    }}

Внутри плагина мы сопоставляем значения полей с их названиями, удаляем исходное поле message (а также поля tenant-id и schema-version), которое содержало запись из лога, и можем добавить произвольное поле, которое будет, например, содержать имя приложения из которого мы собираем логи.

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

Числовые поля будут распознаны как текст, что не позволяет выполнять операции с ними. А именно, поля time-taken лога IIS, а также поля recipient-count и total-bites лога Tracking.
Стандартный временной штамп документа будет содержать время обработки лога, а не время записи его на стороне сервера.
Поле recipient-address будет выглядеть одной стройкой, что не позволяет проводить анализ с подсчётом получателей писем.

Настало время добавить немного магии в процесс обработки логов.

Конвертация числовых полей


Плагин dissect имеет опцию convert_datatype, которую можно использовать для конвертации текстового поля в цифровой формат. Например, так:

dissect {    convert_datatype => { "time-taken" => "int" }  }

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

Для логов трэкинга аналогичный метод convert лучше не использовать, так как поля recipient-count и total-bites могут быть пустыми. Для конвертации этих полей лучше использовать плагин mutate:

mutate {  convert => [ "total-bytes", "integer" ]  convert => [ "recipient-count", "integer" ]}

Разбиение recipient_address на отдельных получателей


Эту задачу можно также решить с помощью плагина mutate:

mutate {  split => ["recipient_address", ";"]}

Изменяем timestamp


В случае с логами трэкинга задача очень просто решается плагином date, который поможет прописать в поле timestamp дату и время в нужном формате из поля date-time:

date {  match => [ "date-time", "ISO8601" ]  timezone => "Europe/Moscow"  remove_field => [ "date-time" ]}

В случае с логами IIS нам будет необходимо объединить данные полей date и time с помощью плагина mutate, прописать нужную нам временную зону и поместить этот временной штамп в timestamp с помощью плагина date:

mutate {   add_field => { "data-time" => "%{date} %{time}" }  remove_field => [ "date", "time" ]}date {   match => [ "data-time", "YYYY-MM-dd HH:mm:ss" ]  timezone => "UTC"  remove_field => [ "data-time" ]}

Output


Секция output используется для отправки обработанных логов в приёмник логов. В случае отправки напрямую в Elastic используется плагин elasticsearch, в котором указывается адрес сервера и шаблон имени индекса для отправки сформированного документа:

output {  elasticsearch {    hosts => ["127.0.0.1:9200", "127.0.0.2:9200"]    manage_template => false    index => "Exchange-%{+YYYY.MM.dd}"  }}

Итоговая конфигурация


Итоговая конфигурация будет выглядеть следующим образом:

input {  beats {    port => 5044  }} filter {  if "IIS" in [tags] {    dissect {      mapping => {        "message" => "%{date} %{time} %{s-ip} %{cs-method} %{cs-uri-stem} %{cs-uri-query} %{s-port} %{cs-username} %{c-ip} %{cs(User-Agent)} %{cs(Referer)} %{sc-status} %{sc-substatus} %{sc-win32-status} %{time-taken}"      }      remove_field => ["message"]      add_field => { "application" => "exchange" }      convert_datatype => { "time-taken" => "int" }    }    mutate {       add_field => { "data-time" => "%{date} %{time}" }      remove_field => [ "date", "time" ]    }    date {       match => [ "data-time", "YYYY-MM-dd HH:mm:ss" ]      timezone => "UTC"      remove_field => [ "data-time" ]    }  }  if "Tracking" in [tags] {    csv {      columns => ["date-time","client-ip","client-hostname","server-ip","server-hostname","source-context","connector-id","source","event-id","internal-message-id","message-id","network-message-id","recipient-address","recipient-status","total-bytes","recipient-count","related-recipient-address","reference","message-subject","sender-address","return-path","message-info","directionality","tenant-id","original-client-ip","original-server-ip","custom-data","transport-traffic-type","log-id","schema-version"]      remove_field => ["message", "tenant-id", "schema-version"]      add_field => { "application" => "exchange" }    }    mutate {      convert => [ "total-bytes", "integer" ]      convert => [ "recipient-count", "integer" ]      split => ["recipient_address", ";"]    }    date {      match => [ "date-time", "ISO8601" ]      timezone => "Europe/Moscow"      remove_field => [ "date-time" ]    }  }} output {  elasticsearch {    hosts => ["127.0.0.1:9200", "127.0.0.2:9200"]    manage_template => false    index => "Exchange-%{+YYYY.MM.dd}"  }}

Полезные ссылки:

How to install OpenJDK 11 on Windows?
Download Logstash
Elastic uses depricated option UseConcMarkSweepGC #36828
NSSM
Persistent Queues
Beats input plugin
Logstash Dude, where's my chainsaw? I need to dissect my logs
Dissect filter plugin
Conditionals
Mutate filter plugin
Date filter plugin
Elasticsearch output plugin
Подробнее..

Microsoft отчиталась об успешном проведении эксперимента по созданию подводного дата-центра

15.09.2020 14:04:30 | Автор: admin
Летом 2018 года в рамках второй фазы испытаний проекта Natick по производству и эксплуатации экологичных и автономных сетевых систем, команда инженеров затопила в прибрежных водах Шотландии контейнер с небольшим дата-центром внутри.



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

Microsoft Project Natick это многолетние исследование по изучению методов производства и эксплуатации экологически устойчивых предварительно укомплектованных ЦОД стандартизированного формата и размера, которые можно быстро развернуть и оставить на годы с выключенным светом на морском дне.

Официальный блог проекта

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

Проект Natick начался еще в 2015 году. Тогда команда инженеров Microsoft разработала концепцию дата-центра в затопленном контейнере и провела испытания первого прототипа, названного Leona Philpot.


Leona Philpot пробный дата-центр в контейнере разработки Microsoft, август 2015 года

Именно на Leona Philpot инженеры Microsoft опробовали систему охлаждения оборудования за счет естественной внешней среды морской воды. Испытания проводились в Тихом океане, в 1 километре от побережья США. Конкретные локации не упоминаются, но, судя по пейзажам на фотографиях, слишком далеко на север инженеры тогда не забрались: вполне вероятно, первые испытания проводились вблизи побережья Калифорнии.

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


Сборка Leona Philpot на берегу перед погружением

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

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

В 2018 году эксперимент повторился. На этот раз инженеры собрали конфигурацию, близкую к коммерческой: выросло число серверов внутри контейнера, да и сам контейнер стал по размерам больше похож на железнодорожную цистерну, чем на бочку. Если быть точным, то это и есть цистерна. За основу корпуса взяли доработанный транспортный контейнер стандарта ISO, который активно используется по всему миру в грузоперевозках. Такое решение сняло вопрос не только по производству корпусов дата-центра, но и по его транспортировке стандартной логистикой к месту погружения. Планируемый ресурс бесперебойной работы итогового продукта пять лет под водой. Прототип получил название Northern Isles Северные острова.


Основные разработчики проекта Natick, слева направо: Майк Шепперд, старший инженер по исследованиям и разработкам, Сэм Огден, старший инженер-программист, Спенсер Фауэрс, старший технический специалист, Эрик Петерсон, исследователь и Бен Катлер, менеджер проекта

Теперь дата-центр затопили в холодных водах Шотландии, недалеко от Оркнейских островов. Контейнер опустили на морское дно, на глубину 35 метров, а подключался он к земле силовым и оптоволоконным кабелем.

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

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



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


Фото загруженной в контейнер мегастойки из 12 серверных стоек, в общей сложности на 864 сервера, 2018 год

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


Дата-центр после двух лет нахождения на морском дне

И вот, вчера, 14 сентября, Microsoft отчиталась о результатах своего эксперимента после подъема дата-центра.

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

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



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



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

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



На правах рекламы


Виртуальные серверы с защитой от DDoS-атак и новейшим железом, серверы размещены в одном из лучших российских дата-центров DataPro. Всё это про наши эпичные серверы. Максимальная конфигурация 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe! Поспешите заказать.

Подробнее..

Обновлённый анонс обновлённых интенсивов Kubernetes oт альфы до омеги

09.09.2020 22:19:00 | Автор: admin

TL;DR, уважаемые хабровчане. Наступила осень, в который раз перевернулся лист календаря и третье сентября наконец-то снова минуло. А значит пора возвращаться к работе и не только к ней, но и к обучению.


У нас, сказала Алиса, с трудом переводя дух, когда долго бежишь со всех ног, непременно попадаешь в другое место.
Какая медлительная страна! сказала Королева. Ну, а здесь, знаешь ли, приходится бежать со всех ног, чтобы только остаться на том же месте! Если же хочешь попасть в другое место, тогда нужно бежать по меньшей мере вдвое быстрее!


Такое ощущение, что они разговаривали об IT-cфере. Настоящий it-специалист в некоторой мере обречён постоянно учиться. Чтобы оставаться просто на необходимом технологическом уровне, нужно каждый год не только актуализировать, но и добавлять знаний процентов на 30.


Этой осенью мы обновили наши интенсивы Kubernetes База и Kubernetes Мега. Интенсивы Слёрма из-за COVID-19 перебрались в онлайн правда с сохранением всех фичей и плюшек. За год много чего произошло. Даже Kubernetes уже лихо помахивает цифрой 1.19.



Kubernetes База


  • Аутсорс инфраструктуры в штыки воспринимается не только бизнес-руководством компании, но и СТО?
  • Решения из гугла в продакшене вместо всё, как по нотам, как обещают инженеры Google, часто превращаются в ад, саранчу, казни египетские и бессонные ночи админа?
  • Вы самостоятельно долго изучали Kubernetes, но так и не приняли решение внедрять его у себя в компании или нет?

Команда Слёрм создала такой формат онлайн-интенсива, что получилась полноценная учеба по 8 часов в день на базе онлайн-инструментов. Есть и формы обратной связи, когда вы можете отправить непонятный вам вопрос на разбор практиков. И обучение на базе Zoom, когда есть возможность пообщаться со спикерами. А сама практика проходит в облаке с доступом по ssh. Про курилку тоже не забыли в телеграм-чате можно обсудить, как проблемы k8s, так и общие впечатления от процесса. В том же чате находятся и техническая поддержка, и сами спикеры.


К слову о спикерах Kubernetes База:



Сергей Бондарев, Архитектор Southbridge. Инженер с 25-летним стажем. Certified Kubernetes Administrator. Огромный опыт внедрения Кубернетес: все куб-проекты Southbridge, включая собственную инфраструктуру. Один из разработчиков kubespray с правами на принятие pull request.


Марсель Ибраев, CTO Слёрм. Инженер с 8-летним стажем. Certified Kubernetes Administrator. Внедрения Кубернетес для клиентов Southbridge. Разработчик курсов и спикер Слёрм.


Александр Швалов, Инженер Southbridge. Администратор с 6-летним стажем. Certified Kubernetes Administrator. Настройка и сопровождение Kubernetes-проектов в Southbridge.


Интенсив пройдёт 28-30 сентября 2020 года.


Подробную программу мероприятия и условия можно прочитать на странице Kubernetes База.


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


Хотите увидеть, как оно будет? Посмотрите, как проходила практика на Вечерней школы Слёрма по Кубернетес.



Небольшой бонус: После оплаты (можно оплатить в рассрочку) интенсива вы получите доступ к Подготовительному курсу по Kubernetes: вводным курсам по технологиям Docker, Ansible и Ceph чтобы легче зашёл интенсив и можно было идти в одном темпе с другими участниками и спикерами.


Kubernetes Мега


Для опытных пользователей Kubernetes нет предела совершенству мы подготовили обновлённый Kubernetes Мега.


На интенсиве разберём в теории и на практике тонкости установки и конфигурации production-ready кластера (the-not-so-easy-way), механизмы обеспечения безопасности и отказоустойчивости приложений.


Спикеры Kubernetes Мега:



Павел Селиванов, Senior DevOps-инженер в Mail.ru MCS. Ведущий DevOps-инженер в Mail.ru Cloud Solutions. На счету десятки выстроенных инфраструктур и сотни написанных пайплайнов CI/CD. Certified Kubernetes Administrator. Автор нескольких курсов по Kubernetes и DevOps. Регулярный докладчик на Российских и международных IT конференциях.


Сергей Бондарев, Архитектор Southbridge. Инженер с 25-летним стажем. Certified Kubernetes Administrator. Внедрения Кубернетес: все куб-проекты Southbridge, включая собственную инфраструктуру. Один из разработчиков kubespray с правами на принятие pull request.


Марсель Ибраев, CTO Слёрм. Инженер с 8-летним стажем. Certified Kubernetes Administrator. Внедрения Кубернетес для клиентов Southbridge. Разработчик курсов и спикер Слёрм.


Kubernetes Мега пройдёт с 14 по 16 октября 2020 года.


Подробную программу интенсива и условия вы можете прочитать на странице Kubernetes Мега.


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


Kubernetes База + Kubernetes Мега дают все материалы, необходимые для сдачи экзамена на CKA в CNCF.


May the k8s be with you!

Подробнее..

Перевод Оценка производительности CNI для Kubernetes по 10G сети (август 2020)

12.09.2020 00:10:18 | Автор: admin


TL;DR: Все CNI работают как надо, за исключением Kube-Router и Kube-OVN, Calico за исключением автоматического определения MTU лучше всех.


Статья-обновление моих прошлых проверок (2018 и 2019), на момент тестирования я использую Kubernetes 1.19 в Ubuntu 18.04 с обновленными CNI на август 2020 года.


Прежде чем погрузиться в метрики...


Что нового с апреля 2019?


  • Можно протестировать на собственном кластере: можно запускать тесты на собственном кластере с использованием нашего инструмента Kubernetes Network Benchmark: knb
  • Появились новые участники
  • Новые сценарии: текущие проверки запускают тесты производительности сети "Pod-to-Pod", также добавлен новый сценарий "Pod-to-Service", запускающий тесты, приближенные к реальным условиям. На практике ваш Pod с API работает с базой в виде сервиса, а не через Pod ip-адрес (конечно же мы проверяем и TCP и UDP для обоих сценариев).
  • Потребление ресурсов: каждый тест сейчас имеет собственное сравнение ресурсов
  • Удаление тестов приложений: мы больше не делаем тесты HTTP, FTP и SCP, поскольку наше плодотворное сотрудничество с сообществом и сопровождающими CNI обнаружило пробел между результатами iperf по TCP и результатами curl из-за задержки в запуске CNI (первые несколько секунд при запуске Pod, что не характерно в реальных условиях).
  • Открытый исходный код: все источники тестов (скрипты, настройки yml и исходные "сырые" данные) доступны здесь

Эталонный протокол тестирования


Протокол подробно описан здесь, обратите внимание, что эта статья посвящена Ubuntu 18.04 с ядром по умолчанию.


Выбор CNI для оценки


Это тестирование нацелено на сравнение CNI, настраиваемых одним файлом yaml (поэтому исключены все, устанавливаемые скриптами, типа VPP и прочих).


Выбранные нами CNI для сравнения:


  • Antrea v.0.9.1
  • Calico v3.16
  • Canal v3.16 (Flannel network + Calico Network Policies)
  • Cilium 1.8.2
  • Flannel 0.12.0
  • Kube-router latest (20200825)
  • WeaveNet 2.7.0

Настройка MTU для CNI


В первую очередь проверяем влияние автоматического определения MTU на производительность TCP:



Влияние MTU на производительность TCP


Еще больший разрыв обнаруживается при использовании UDP:



Влияние MTU на производительность UDP


С учетом ОГРОМЕННОГО влияния на производительность, раскрытого в тестах, мы хотели бы отправить письмо-надежду всем сопровождающим CNI: пожалуйста, добавьте автоматическое определение MTU в CNI. Вы спасете котяток, единорожек и даже самого симпатичного: маленького девопсика.
Тем не менее если вам по-любому надо взять CNI без поддержки автоматического определения MTU можно настроить его руками для получения производительности. Обратите внимание, что это относится к Calico, Canal и WeaveNet.



Моя маленькая просьба к сопровождающим CNI...


Тестирование CNI: необработанные данные


В этом разделе мы сравним CNI с правильным MTU (определенным автоматически, либо выставленным руками). Основная цель здесь показать в виде графиков необработанные данные.


Цветовая легенда:


  • серый образец (т.е. голое железо)
  • зеленый пропускная способность выше 9500 мбит\с
  • желтый пропускная способность выше 9000 мбит\с
  • оранжевый пропускная способность выше 8000 мбит\с
  • красный пропускная способность ниже 8000 мбит\с
  • синий нейтральный (не связано с пропускной способностью)

Потребление ресурсов без нагрузки


В первую очередь проверка потребления ресурсов, когда кластер "спит".



Потребление ресурсов без нагрузки


Pod-to-Pod


Этот сценарий подразумевает, что клиентский Pod подключается напрямую к серверному Pod по его ip-адресу.



Сценарий Pod-to-Pod


TCP


Результаты Pod-to-Pod TCP и соответствующее потребление ресурсов:




UDP


Результаты Pod-to-Pod UDP и соответствующее потребление ресурсов:




Pod-to-Service


Этот раздел актуален для реальных случаев использования, клиентский Pod соединяется с серверным Pod через сервис ClusterIP.



Сценарий Pod-to-Service


TCP


Результаты Pod-to-Service TCP и соответствующее потребление ресурсов:




UDP


Результаты Pod-to-Service UDP и соответствующее потребление ресурсов:




Поддержка политик сети


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


Шифрование CNI


Среди проверяемых CNI есть те, что могут шифровать обмен по сети между Pod:


  • Antrea с помощью IPsec
  • Calico с помощью wireguard
  • Cilium с помощью IPsec
  • WeaveNet с помощью IPsec

Пропускная способность


Поскольку осталось меньше CNI сведем все сценарии в один график:



Потребление ресурсов


В этом разделе мы будет оценивать ресурсы, используемые при обработке связи Pod-to-Pod в TCP и UDP. Нету смысла рисовать график Pod-to-Service, поскольку он не дает дополнительной информации.




Сводим все вместе


Давайте попробуем повторить все графики, мы тут немного привнесли субъективности, заменяя фактические значения словами "vwry fast", "low" и т.п.



Заключение и мои выводы


Тут немножко субъективно, поскольку я передаю собственную интерпретацию результатов.


Я рад, что появились новые CNI, Antrea выступил неплохо, реализовано много функций даже в ранних версиях: автоматическое определение MTU, шифрование и простая установка.


Если сравнивать производительность все CNI работают хорошо, кроме Kube-OVN и Kube-Router. Kube-Router также не смог определить MTU, я не нашел нигде в документации способа его настройки (тут открыт запрос на эту тему).


Что касается потребления ресурсов, то по-прежнему Cilium использует больше оперативной памяти, чем другие, но компания-производитель явно нацелена на крупные кластеры, что явно не то же самое, как тест на трехузловом кластере. Kube-OVN также потребляет много ресурсов процессорного времени и оперативной памяти, но это молодой CNI, основанный на Open vSwitch (как и Antrea, работающий лучше и с меньшим потреблением).


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


Также кроме прочего, производительность шифрования настроящий восторг. Calico один из старейших CNI, но шифрование было добавлено всего пару недель назад. Они выбрали wireguard вместо IPsec, и проще говоря, все работает великолепно и потрясно, полностью вытесняя другие CNI в этой части тестирования. Конечно же растет потребление ресурсов из-за шифрования, но достигаемая пропускная способность того стоит (Calico в тесте с шифрованием показал шестикратное превосходство по сравнению с Cilium, занимающим второе место). Больше того, можно включить wireguard в любое время после развертывания Calico в кластере, а также, если пожелаете, можете отключить его на короткое время или навсегда. Это невероятно удобно, но! Мы напоминаем, что Calico не умеет сейчас автоматически определять MTU (эта функция запланирована в следующих версиях), так что не забывайте настраивать MTU, если ваша сеть поддерживает Jumbo Frames (MTU 9000).


Кроме прочего, обратите внимание, что Cilium умеет шифровать трафик между узлами кластера (а не только между Pod), что может быть весьма актуально для публичных узлов кластера.


В качестве заключения я предлагаю следующие варианты использования:


  • Нужен CNI для сильно мелкого кластера, ИЛИ мне не нужна безопасность: работайте с Flannel, наиболее легким и стабильным CNI (он же один из старейших, его по легенде изобрел Homo Kubernautus или Homo Contaitorus). Также вас возможно заинтересует гениальнейший проект k3s, проверьте!
  • Нужен CNI для обычного кластера: Calico ваш выбор, но не забывайте настроить MTU, если оно нужно. Легко и непринужденно можно играть с сетевыми политиками, включать и выключать шифрование и т.п.
  • Нужен CNI для (очень) крупномасштабного кластера: ну, тест не показывает поведение больших кластеров, я был бы рад провести тесты, но у нас нету сотен серверов с подключением 10гбит\с. Так что лучший вариант запуск модифицированного теста на ваших узлах, хотябы с Calico и Cilium.
Подробнее..

Перевод Google добавил поддержку Kubernetes в Confidential Computing

14.09.2020 20:08:14 | Автор: admin

TL;DR: Теперь можно запустить Kubernetes на Confidential VMs от Google.



Компания Google сегодня (08.09.2020, прим. переводчика) на мероприятии Cloud Next OnAir сообщила о расширении линейки своих продуктов запуском нового сервиса.


Узлы Confidential GKE добавляют больше секретности нагрузкам, запущенным в Kubernetes. В июле был запущен первый продукт под названием Confidential VMs, а сегодня эти виртуальные машины уже общедоступны всем.


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


Инициатива Confidential Computing от Google основана на сотрудничестве с консорциумом Confidential Computing, отраслевой группой для продвижения концепции надежных окружений исполнения (Trusted Execution Environments, TEEs). TEE защищенная часть процессора, в которой загруженные данные и код зашифрованы, что означает невозможность получения доступа к этой информации другими частями этого же процессора.


Confidential VMs от Google работают на виртуальных машинах N2D, запущенных на процессорах второго поколения EPYC компании AMD, использующих технологию Secure Encrypted Virtualization, позволяющую изолировать виртуальные машины от гипервизора, на котором они работают. Есть гарантия того, что данные остаются зашифрованными вне зависимости от их использования: рабочие нагрузки, аналитика, запросы на тренировку моделей для искуственного интеллекта. Эти виртуальные машины разработаны для удовлетворения потребностей любой компании, работающей с секретными данными в регулируемых областях, например в банковской отрасли.


Возможно более насущным является анонс о предстоящем beta-тестировании узлов Confidential GKE, которые, по словам Google, будут представлены в предстоящем выпуске 1.18 Google Kubernetes Engine (GKE). GKE управляемое, готовое к внедрению на производстве окружение для запуска контейнеров, в которых размещаются части современных приложений, которые можно запускатьв нескольких вычислительных окружениях. Kubernetes инструмент оркестровки с открытым исходным кодом, используемый для управления этими контейнерами.


Добавление узлов Confidential GKE обеспечивает большую секретность при запуске кластеров GKE. При добавлении нового продукта в линейке Confidential Computing мы хотели обеспечить новый уровень
секретности и переносимости для контейнеризированных нагрузок. Узлы Confidential GKE от Google построены на той же технологии, что и Confidential VMs, позволяют вам шифровать данные в оперативной памяти с помощью уникального для каждого узла ключа шифрования, создаваемого и управляемого процессором AMD EPYC. Такие узлы будут использовать аппаратное шифрование оперативной памяти на jснове функции SEV от компании AMD, что означает, что ваши рабочие нагрузки, выполняемые на таких узлах, будут зашифрованы во время их работы.

Sunil Potti и Eyal Manor, инженеры по облачным технологиям, Google


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


Многим предприятиям нужно еще больше секретности при использовании публичных облачных сервисов, чем для локальных рабочих нагрузок, запускаемых на своих мощностях, что нужно для защиты от злоумышленников. Google Cloud расширяя свою линейку Confidential Computing повышает эту планку, предоставляя пользователям возможность обеспечения секретности для кластеров GKE. А с учетом популярности Kubernetes это ключевой шаг вперед для отрасли, дающий компаниям больше возможностей для безопасного размещения приложений следующего поколения в публичном облаке.

Holger Mueller, аналитик Constellation Research.


N.B. Наша компания 28-30 сентября запускает обновлённый интенсив Kubernetes База для тех, кто ещё не знает Kubernetes, но хочет с ним познакомиться и начать работать. А после этого мероприятия 1416 октября мы запускаем обновлённый Kubernetes Мега для опытных пользователей Kubernetes, которым важно знать все последние практические решения в работе с Kubernetes последних версий и возможные грабли. На Kubernetes Мега разбирём в теории и на практике тонкости установки и конфигурации production-ready кластера (the-not-so-easy-way), механизмы обеспечения безопасности и отказоустойчивости приложений.

Кроме прочего Google заявила, что ее Confidential VMs получат некоторые новые возможности, поскольку они становятся общедоступными с этого дня. Например появились отчеты аудита, содержащие подробные журналы проверки целостности прошивки AMD Secure Processor, используемой для создания ключей для каждого экземпляра Confidential VMs.


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


Вы можете использовать комбинацию общих VPC с правилами firewall и ограничениями политики огранизации для обеспечения уверенности в том, что Confidential VMs могут обмениваться данными с другими Confidential VMs, даже если они работают в разных проектах. Кроме этого вы можете использовать VPC Service Controls для задания области ресурсов GCP для ваших Confidential VMs.

Sunil Potti и Eyal Manor

Подробнее..

Хранение данных в кластере Kubernetes

15.09.2020 02:12:09 | Автор: admin

Настроить хранение данных приложений, запущенных в кластере Kubernetes, можно несколькими способами. Одни из них уже устарели, другие появились совсем недавно. В этой статье рассмотрим концепцию трёх вариантов подключения СХД, в том числе самый последний подключение через Container Storage Interface.



Способ 1. Указание PV в манифесте пода


Типичный манифест, описывающий под в кластере Kubernetes:



Цветом выделены части манифеста, где описано, какой том подключается и куда.


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


В разделе x перечисляют все тома, которые используются в поде. Указывают имя каждого тома, а также тип (в нашем случае: awsElasticBlockStore) и параметры подключения. Какие именно параметры перечисляются в манифесте, зависит от типа тома.


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


Этот способ подключения придумали в самом начале, когда Kubernetes только зарождался, и на сегодня способ устарел.


При его использовании возникает несколько проблем:


  1. все тома надо создавать вручную, Kubernetes не сможет создать ничего за нас;
  2. параметры доступа к каждому из томов уникальные, и их надо указывать в манифестах всех подов, которые используют том;
  3. чтобы поменять систему хранения (например, переехать из AWS в Google Cloud), надо менять настройки и тип подключённых томов во всех манифестах.

Всё это очень неудобно, поэтому в реальности подобным способом пользуются для подключения только некоторых специальных типов томов: configMap, secret, emptyDir, hostPath:


  • configMap и secret служебные тома, позволяют создать в контейнере том с файлами из манифестов Kubernetes.


  • emptyDir временный том, создаётся только на время жизни пода. Удобно использовать для тестирования или хранения временных данных. Когда pod удаляется, том типа emptyDir тоже удаляется и все данные пропадают.


  • hostPath позволяет смонтировать внутрь контейнера с приложением любой каталог локального диска сервера, на котором работает приложение, в том числе /etc/kubernetes. Это небезопасная возможность, поэтому обычно политики безопасности запрещают использовать тома этого типа. Иначе приложение злоумышленника сможет замонтировать внутрь своего контейнера каталог HTC Kubernetes и украсть все сертификаты кластера. Как правило, тома hostPath разрешают использовать только системным приложениям, которые запускаются в namespace kube-system.



Cистемы хранения данных, с которыми Kubernetes работает из коробки приведены в документации.


Способ 2. Подключение к подам SC/PVC/PV


Альтернативный способ подключения концепция Storage class, PersistentVolumeClaim, PersistentVolume.


Storage class хранит параметры подключения к системе хранения данных.


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


Суть идеи: в манифесте пода указывают volume типа PersistentVolumeClaim и указывают название этой сущности в параметре claimName.



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


  • размер диска;
  • способ доступа: ReadWriteOnce или ReadWriteMany;
  • ссылка на Storage class в какой системе хранения данных мы хотим создавать том.

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


В манифестах PersistentVolume указывается Storage class и параметры доступа к конкретному тому (ID тома, путь, и т. д.).


Создавая PVC, Kubernetes смотрит, том какого размера и из какого Storage class потребуется, и подбирает свободный PersistentVolume.


Если таких PV нет в наличии, Kubernetes может запустить специальную программу Provisioner (её название указывают в Storage class). Эта программа подключается к СХД, создаёт том нужного размера, получает идентификатор и создает в кластере Kubernetes манифест PersistentVolume, который связывается с PersistentVolumeClaim.


Всё это множество абстракций позволяет убрать информацию о том, с какой СХД работает приложение, с уровня манифеста приложений на уровень администрирования.


Все параметры подключения к системе хранения данных находятся в Storage class, за который отвечают администраторы кластера. Всё, что надо сделать при переезде из AWS в Google Cloud, это в манифестах приложения изменить название Storage class в PVC. Persistance Volume для хранения данных будут созданы в кластере автоматически, с помощью программы Provisioner.


Способ 3. Container Storage Interface


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


Чтобы решить проблему, разработчики из Cloud Foundry, Kubernetes, Mesos и Docker создали Container Storage Interface (CSI) простой унифицированный интерфейс, который описывает взаимодействие системы управления контейнерами и специального драйвера (CSI Driver), работающего с конкретной СХД. Весь код по взаимодействию с СХД вынесли из ядра Kubernetes в отдельную систему.


Документация по Container Storage Interface.


Как правило, CSI Driver состоит из двух компонентов: Node Plugin и Controller plugin.


Node Plugin запускается на каждом узле и отвечает за монтирование томов и за операции на них. Controller plugin взаимодействует с СХД: создает или удаляет тома, назначает права доступа и т. д.


Пока в ядре Kubernetes остаются старые драйверы, но пользоваться ими уже не рекомендуют и всем советуют устанавливать CSI Driver конкретно для той системы, с которой предстоит работать.


Нововведение может напугать тех, кто уже привык настраивать хранение данных через Storage class, но на самом деле ничего страшного не случилось. Для программистов точно ничего не меняется они как работали только с именем Storage class, так и продолжат. Для администраторов добавилась установка helm chart и поменялась структура настроек. Если раньше настройки вводились в Storage class напрямую, то теперь их сначала надо задать в helm chart, а потом уже в Storage class. Если разобраться, ничего страшного не произошло.


Давайте, на примере, рассмотрим какие преимущества можно получить, перейдя на подключение СХД Ceph с помощью CSI драйвера.


При работе с Ceph плагин CSI даёт больше возможностей для работы с СХД, чем встроенные драйверы.


  1. Динамическое создание дисков. Обычно диски RBD используются только в режиме RWO, а CSI для Ceph позволяет использовать их в режиме RWX. Несколько pod'ов на разных узлах могут смонтировать один и тот же RDB-диск к себе на узлы и работать с ними параллельно. Справедливости ради, не всё так лучезарно этот диск можно подключить только как блочное устройство, то есть придётся адаптировать приложение под работу с ним в режиме множественного доступа.
  2. Создание снапшотов. В кластере Kubernetes можно создать манифест с требованием создать снапшот. Плагин CSI его увидит и сделает снапшот с диска. На его основании можно будет сделать либо бэкап, либо копию PersistentVolume.
  3. Увеличение размера диска на СХД и PersistentVolume в кластере Kubernetes.
  4. Квоты. Встроенные в Kubernetes драйверы CephFS не поддерживают квоты, а свежие CSI-плагины со свежим Ceph Nautilus умеют включать квоты на CephFS-разделы.
  5. Метрики. CSI-плагин может отдавать в Prometheus множество метрик о том, какие тома подключены, какие идут взаимодействия и т. д.
  6. Topology aware. Позволяет указать в манифестах, как географически распределён кластер, и избежать подключения к подам, запущенным в Лондоне системы хранения данных, расположенной в Амстердаме.

Как подключить Ceph к кластеру Kubernetes через CSI, смотрите в практической части лекции вечерней школы Слёрм. Так же можно подписаться на видео-курс Ceph, который будет запущен 15 октября.


Автор статьи: Сергей Бондарев, практикующий архитектор Southbridge, Certified Kubernetes Administrator, один из разработчиков kubespray.


Немного Post Scriptum не рекламы для, а пользы ради...

P.S. Сергей Бондарев ведёт два интенсива: обновлённый Kubernetes База 28-30 сентября и продвинутый Kubernetes Мега 1416 октября.


Подробнее..

Обзор возможностей Kubespray Отличие оригинальной версии и нашего форка

20.09.2020 14:22:27 | Автор: admin

23 сентября 20.00 МСК Сергей Бондарев проведёт бесплатный вебинар Обзор возможностей Kubespray, где расскажет, как готовят kubespray, чтобы получилось быстро, эффективно и отказоустойчиво.


Сергей Бондарев расскажет отличие оригинальной версии и нашего форка:



Отличие оригинальной версии и нашего форка.


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


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


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

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


В итоге разница между кластерами, созданными моим форком и оригинальным это kube-proxy и сроки действия сертификатов.


В моем форке все осталось, как было раньше куб-прокси запускается, как статик под, сертификаты выписываются на 100 лет.


В Kubeadm куб-прокси запускается, как daemonset, а сертификаты выписываются на 1 год, и их надо периодически продлевать. kubeadm наконец-то научился это делать одной командой.


Разница небольшая, и на сегодня мы используем оба варианта.


Особенности (недостатки) при промышленной эксплуатации:


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


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


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


Например у меня была проблема с кубадмом, когда он падал в момент добавления второго и третьего мастера, и после этого кубспрей делал kubeadm reset на узле, и пробовал добавить мастер еще раз.


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


Opensource как он есть.


Всё это и многое другое на бесплатном вебинаре Обзор возможностей Kubespray 23 сентября 20.00 МСК.


Присоединяйтесь!

Подробнее..

АйТиБалаган! 3 Зачем DevOps-инженеру программирование и что такое виртуализация

21.09.2020 14:20:44 | Автор: admin

IT-балаганят, спорят, делятся кейсами:



Темы:


  • Что такое DevOps;
  • Зачем разработчику уметь в DevOps;
  • Зачем DevOps-инженеру уметь в программирование?
  • Виртуализация VS контейнеризация;
  • Минимальный набор знаний по DevOps в 2к20;
  • Будущее DevOps;
  • VMWare юзкейсы;
  • VMWorld 2020 онлайн что за зверь?

Навигация:


О DevOps и всём-всём-всём...

0:00 Начало;
3:35 Представление гостей;
7:38 Что такое DevOps;
33:30 Зачем DevOps-инженеру программирование;
41:40 Фреймворки в DevOps;
49:50 Как уживаться разработчикам и девопсеру;
1:12:40 Будущее DevOps;
1:19:30 Минимальный набор знаний для девопсера;
1:26:30 Перерыв;
1:32:20 Девопс это сисадмин для программистов?
1:34:40 Про зарплаты;
1:38:00 Про контейнеризацию;
1:47:55 Про продукты VWware и виртуализацию;
1:57:15 Про VMWorld;
2:00:20 Конференции и ресурсы по девопсу;
2:10:00 Как быть с большим объемом информации в профессии;
2:23:23 Про безопасность и DevOps;
2:48:10 Куда развиваться девопсеру.


P.S. В АйТиБалагане раз и не два поминался SRE. Если тема вам интересна, и есть желания стать SRE-инженером, то есть смысл присмотреться к онлайн-интенсиву SRE. На три дня вы погрузитесь в теорию и практику SRE: разработаете и будете поддерживать сайт, состоящий из нескольких микросервисов. Научитесь правильно распределять ограниченные ресурсы для обеспечения быстродействия, отказоустойчивости и доступности сайта для максимальной надежности, достаточной, чтобы были довольны пользователи. 1113 декабря сего года wellcome!


Спикеры курса SRE

Подробнее..

Наиболее интересные факты о Ceph по результатам опроса пользователей в 2019 году

23.09.2020 00:14:39 | Автор: admin
TL;DR: наиболее интересные факты о Ceph в таблицах и графиках, полученных из результатов опроса пользователей Ceph в 2019 году.



Какой у вас тип организации?


Ответили на вопрос: 405
Пропустили вопрос: 0
Ответ Ответили %
Коммерческая 257 63.46
Правительственная 19 4.69
Военная 0 0
Образовательная 57 14.07
Некоммерческая 16 3.95
Другая 56 13.82



Почему используете Ceph?


Ответили на вопрос: 405
Пропустили вопрос: 0
Ответ Ответили %
Открытый исходный код 367 90.62
Масштабируемость 326 80.49
Стоимость 247 60.99
Функционал 223 55.06
Отказоустойчивость 309 76.30
Надежность\живучесть\целостность данных 279 68.89
Производительность 125 30.86
Возможность внедрения со смежными технологиями 120 29.63
Другое 13 3.21



Как давно используете Ceph?


Ответили на вопрос: 405
Пропустили вопрос: 0
Ответ Ответили %
Менее года 72 17.78
1-2 года 65 16.05
2-5 лет 203 50.12
Более 5 лет 58 14.32
Не пользуюсь 7 1.73



В каких странах у вас развернут Ceph?


Ответили на вопрос: 405
Пропустили вопрос: 0
Ответ Ответили %
Другая 249 61.48
США 87 21.48
Германия 73 18.02
Китай 30 7.41
Великобритания 29 7.16
Россия 26 6.42
Франция 20 4.94



Как устанавливаете Ceph?


Ответили на вопрос: 344
Пропустили вопрос: 61
Ответ Ответили %
Пакеты от разработчиков 170 49.42
Пакеты из дистрибутивов 131 38.08
Пакеты от производителей 93 27.03
Собираем свои пакеты 26 7.56
Собираем свою версию 12 3.49



N.B. Если всё ещё немного плаваете в вопросах, как устанавливать и разворачивать правильно Ceph c 15 октября запускается курс по Ceph от практиков. Вы изначально получите системные знания по базовым понятиям и терминам, а по окончании курса научитесь полноценно устанавливать, настраивать и управлять Ceph.


Как разворачиваете?


Ответили на вопрос: 312
Пропустили вопрос: 93
Ответ Ответили %
Ansible 134 42.95
ceph-deploy 133 42.63
Другое (тут Proxmox + CLI) 75 24.04



Применяемая операционная система


Ответили на вопрос: 344
Пропустили вопрос: 61
Ответ Ответили %
Ubuntu 131 38.08
Debian 101 29.36
CentOS 125 36.34
RHEL 34 9.88
SLES\OpenSuse 21 6.10
Другая 55 15.99



Какое оборудование применяете?


Ответили на вопрос: 343
Пропустили вопрос: 62
Ответ Ответили %
Supermicro 171 50.00
Dell 131 38.30
HPE 89 26.02
Другое 162 47.23



Какие накопители применяете?


Ответили на вопрос: 342
Пропустили вопрос: 63
Ответ Ответили %
HDD 305 89.18
SSD (SAS, SATA) 261 76.32
NVMe 161 47.08
Другие 21 6.14



Используете отдельную сеть для OSD?


Ответили на вопрос: 342
Пропустили вопрос: 63
Ответ Ответили %
Да 249 72.81
Нет 93 27.19


Какое ПО используете совместно с Ceph?


Ответили на вопрос: 340
Пропустили вопрос: 65
Ответ Ответили %
RBD на Linux серверах 123 36.18
Proxmox 114 33.53
KVM 105 30.88
OpenStack 97 28.53
Kubernetes 88 25.88
Другое 178 52.35



Для чего используете RBD?


Ответили на вопрос: 295
Пропустили вопрос: 110
Ответ Ответили %
Виртуализация 232 78.64
Резервное копирование 133 45.08
Облака 122 41.36
Контейнеры 117 39.66
Архивное хранилище 94 31.86



Для чего используете RGW?


Ответили на вопрос: 163
Пропустили вопрос: 242
Ответ Ответили %
Архивное хранение 105 64.42
Резервное копирование 92 56.44
Big data и аналитика 61 37.42



Для чего используете CephFS?


Ответили на вопрос: 184
Пропустили вопрос: 221
Ответ Ответили %
NAS общего назначения 98 53.26
Резервное копирование 87 47.28
Домашние каталоги 63 34.24
Архивное хранение 54 29.35
Media\Streaming 44 23.91



Какой мониторинг используете?


Ответили на вопрос: 312
Пропустили вопрос: 93
Ответ Ответили %
Ceph Dashboard 170 54.49
Grafana (свои настройки) 135 43.27
Prometheus 126 40.38
Proxmox 91 29.17
Zabbix 60 19.23
Nagios\Icinga 54 17.31



N.B. Если есть необходимость подтянуть, а то и научиться правильному логированию и мониторингу, добро пожаловать на курс Мониторинг и логирование инфраструктуры в Kubernetes. Сейчас можно приобрести курс с существенной скидкой. На курсе узнаете Узнаете, что именно мониторить, какие метрики собирать и как настраивать алерты для оперативного поиска и устранения проблем в кластере. Какие метрики стоит собирать с помощью Prometheus? Как визуализировать мониторинг с помощью Grafana и как грамотно настроить алерты?
Данные для графиков взяты отсюда.
Подробнее..

1113 декабря онлайн-интенсив SRE Одна из самых востребованных IT-профессий в мире

24.09.2020 14:19:46 | Автор: admin

Как совсем недавно была мода и высокий спрос на DevOps-инженеров, так сейчас рекрутеры крупнейших компаний ищут Site Reliability Engineer. Достаточно зайти на сайты крупнейших компаний, лидеров IT-рынка, чтобы в этом убедиться. Apple, Google, Booking, Amazon.


Site Reliability Engineering это билет в открытый мир IT. Любая страна, любая IT-компания.


От Apple до Google






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


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



Что будет на курсе:


Строить


Сформулируете показатели SLO, SLI, SLA для сайта, состоящего из нескольких
микросервисов, разработаете архитектуру и инфраструктуру, которая их обеспечит,
соберете, протестируете и задеплоите сайт, настроите мониторинг и алертинг.


Ломать


Рассмотрите внутренние и внешние факторы ухудшения SLO: ошибки разработчиков, отказы инфраструктуры, наплыв посетителей, DoS-атаки. Разберетесь в устойчивости, error budget, практике тестирования, управлении прерываниями и операционной
нагрузкой.


Чинить


Организуете работу группы по ликвидации аварии в минимальные сроки: подключение коллег, оповещение интересантов (stakeholders), выстраивание приоритетов. Имитация реальных условий: восстановление работоспособности сервиса в условиях предельно ограниченного времени.


Изучать


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


Преподавать вам будут спикеры-практики:



Интенсив пройдёт в декабре 2020, а именно 1113 декабря. Каждый день начинаем в 10:00, проверка связи в 9:45. По расписанию занятия идут до 19:00 с перерывом на обед.


Детальную программу курса и условия вы можете увидеть на сайте курса по SRE.


Пока ещё действует акционное предложение. Осталось 28 мест из 30.


Никогда не поздно всё поменять!

Подробнее..

Перевод Как меняется бизнес Docker для обслуживания миллионов разработчиков, часть 1 Хранилище

24.09.2020 16:22:36 | Автор: admin


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


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


Подробный анализ образов Docker Hub


Доставка приложений переносимым, безопасным и ресурсоэффективным способом требует инструменты и сервисы для безопасного хранения и совместного использования для вашей команды разработчиков. На сегодняшний день Docker с гордостью предлагает крупнейший в мире registry для образов контейнеров, Docker Hub, используемый более 6.5 миллионов разработчиков по всему миру. В настоящее время в Docker Hub хранится более 15ПБ образов контейнеров, охватывающих всё, начиная от популярнейших баз данных с хранением данных в оперативной памяти, и заканчивая платформами поточной передачи событий, тщательно отобранных и доверенных официальных образов Docker, а также порядка 150 миллионов образов, созданных сообществом Docker.


Согласно отчету, полученному нашими внутренними аналитическими инструментами, из 15 ПБ образов, хранящихся в Docker Hub, более 10ПБ не использовалось более полугода. Мы обнаружили, копнув глубже, что более 4.5ПБ этих неактивных образов связаны с бесплатными учетными записями. Многие такие образы использовались короткое время, включая образы, полученные из конвейеров CI с Docker Hub, настроенных так, что удаление временных образов игнорировалось.


Из-за большого объема неактивных данных, простаивающих в Docker Hub, команда столкнулась со сложным вопросом: как ограничить эти данные, за которые Docker ежемесячно платит, не влияя при этом на остальных клиентов Docker?


Основные принципы, принятые для решения проблемы были такими:


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

Помощь разработчикам в управлении неактивными образами


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


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


  • Пример 1: Молли, пользователь бесплатной учетной записи, закачала в Docker Hub 1 января 2019 года образ с меткой molly/hello-world:v1. Этот образ никогда не скачивался с момента публикации. Этот помеченный образ будет считаться неактивным начиная с 1 ноября 2020 года, когда новая политика начнет действовать. Образ и любая метка, указывающая на него, будут удалены 1 ноября 2020 года.
  • Пример 2: У Молли есть образ без метки molly/myapp@sha256:c0ffee, закачан 1 августа 2018 года. Последнее скачивание было 1 августа 2020 года. Этот образ считается активным, и не будет удален 1 ноября 2020 года.

Минимизация влияния на сообщество разработчиков


Для бесплатных учетных записей Docker предлагает бесплатное хранение неактивных образов в течение полугода. Для тех, кому надо хранить неактивные образы, Docker предлагает неограниченное хранение образов в качестве особенности планов Pro или Team.


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



Наконец, в рамках поддержки сообщества разработчиков ПО с открытым исходным кодом, до 1 ноября мы предоставим новые тарифные планы для открытого исходного кода. Чтобы подать заявку надо заполнить форму тут.


Для получения дополнительной информации о последних изменениях условий обслуживания обратитесь к FAQ.


Следите за сообщениями по e-mail касательно любых образов с истекающим сроком действия, либо перейдите на тарифные планы Pro или Team для хранения неактивных образов без ограничений.


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


P.S. Учитывая то, что технология Docker не теряет актуальности, как заверяют её создатели, совсем не лишним было бы изучить эту технологию от и до. Тем более это всегда в пользу, когда вы выработаете с Kubernetes. Если хотите познакомиться с best practice кейсами, чтобы понять, где и как лучше использовать Docker, рекомендую комплексный видеокурс по Docker, в котором мы разберем все его инструменты. Полная программа курса на странице курса.

Подробнее..

Перевод Как масштабируется бизнес Docker для обслуживания миллионов разработчиков, часть 2 Исходящие данные

26.09.2020 12:23:55 | Автор: admin


Это вторая статья из серии статей, в ней будут рассмотрены ограничения при скачивании образов контейнеров.


В первой части мы подробно рассмотрели образы, хранимые в Docker Hub, крупнейшем registry образов контейнеров. Мы пишем об этом для того, чтобы вы лучше понимали, как наши обновленные Условия обслуживания повлияют на команды разработчиков, использующих Docker Hub для управления образами контейнеров и конвейерами CI\CD.


Об ограничениях по частоте скачивания было объявлено ранее в наших Условиях обслуживания. Мы подробнее рассмотрим ограничения по частоте, которые вступят в силу с 1 ноября 2020 года:


Бесплатный тарифный план, анонимные пользователи: 100 скачиваний за 6 часов
Бесплатный тарифный план, авторизованные пользователи: 200 скачиваний за 6 часов
Тарифный план Pro: без ограничений
Тарифный план Team: без ограничений


Частота скачиваний со стороны Docker определяется как число запросов манифестов к Docker Hub. Ограничения по частоте скачивания образов зависят от типа учетной записи, запрашивающей образ, а не от типа учетной записи владельца образа. Для анонимных (неавторизованных) пользователей частота скачивания привязана к ip-адресу.


N.B. Больше тонкостей и best practice кейcов вы получите на курсе Docker от практиков. Причём вы можете проходить его, когда вам удобно и по времени, и по настрою.


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


Подробный анализ частот скачивания образов Docker Hub


Мы потратили много времени анализируя скачивание образов из Docker Hub, чтобы определить причину ограничения скорости, а также как именно нужно ограничивать. То, что мы увидели, подтвердило, что фактически все пользователи скачивают образы с предсказуемой скоростью для типовых рабочих процессов. Однако есть заметное влияние небольшого числа анонимных пользователей, например порядка 30% всех скачиваний исходят только от 1% анонимных пользователей.



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


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


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


К примеру, если у вас уже есть образ, Docker Engine выдаст запрос на манифест, поймет, что у него уже есть все необходимые слои на основе принятого манифеста, после чего остановится. С другой стороны если вы скачиваете образ, поддерживающий несколько архитектур, запрос на манифест вернет список манифестов образов для каждой поддерживаемой архитектуры. Затем Docker Engine выдаст еще один запрос на манифест касательно конкретной архитектуры, на которой он работает, в ответ получит список всех слоев образа. Затем он будет запрашивать каждый отсутствующий слой (blob).


N.B. Более широко эта тема раскрыта на курсе Docker, в котором мы разберем все его инструменты: от основных абстракций до параметров сети, нюансов работы с различными ОС и языками программирования. Вы познакомитесь с технологией и поймете, где и как лучше использовать Docker.


Получается, что скачивание образа это на самом деле один или два запроса манифеста, а также от нуля и до бесконечности запросы слоев (blob). Исторически Docker отслеживал частоту скачивания на основе слоев, поскольку это наиболее связано с использованием полосы пропускания. Но тем не менее, мы прислушались к сообществу, что так сложнее, ведь нужно отслеживать запрашиваемое число слоев, что приведет к игнорированию best practices касательно работы с Dockerfile, а также интуитивно непонятнее для пользователей, желающих просто работать с registry, не сильно разбираясь в деталях.


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


Ждем ваши отзывы


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


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


Наконец, в рамках поддержки сообщества разработчиков ПО с открытым исходным кодом, до 1 ноября мы предоставим новые тарифные планы для открытого исходного кода. Чтобы подать заявку надо заполнить форму тут.


Для получения дополнительной информации о последних изменениях условий обслуживания обратитесь к FAQ.


Тем, кому надо поднять ограничения на частоту скачивания образов, Docker предлагает неограниченное скачивание образов в качестве особенности планов Pro или Team. Как всегда, мы ждем обратную связь и вопросы здесь.

Подробнее..

Перевод Какие возможности появились у утилиты rdiff-backup благодаря миграции на Python 3

22.09.2020 10:23:41 | Автор: admin
В процессе миграции на Python 3 разработчики утилиты rdiff-backup усовершенствовали её, добавив много новых фич.



В марте 2020 года вышел второй крупный релиз утилиты rdiff-backup. Второй за 11 лет. Во многом, это объясняется прекращением поддержки Python 2. Разработчики решили совместить приятное с полезным и доработали функционал утилиты.

Около 20 лет она верой и правдой служит Linux-сообществу помогает делать бэкапы на локальных и удалённых машинах, скажем так без лишней головной боли. Секрет прост: утилита позволяет делать бэкап только тех файлов, которые изменились с прошлого резервного копирования. Для более краткого обозначения этого процесса существует термин инкрементальное резервное копирование.

Второе рождение rdiff-backup пережила благодаря команде энтузиастов, которую возглавили Эрик Зольф и Патрик Дюфресне из IKUS Software, а также Отто Кекяляйнен из Seravo.


Новые фичи


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

Автоматизация на базе Travis CI


Другое важнейшее улучшение это конвейер CI/CD на базе распределённого веб-сервиса Travis CI. Теперь пользователи смогут запускать rdiff-backup в различных тестовых средах без риска сломать работающий проект. Конвейер CI/CD позволит выполнять автоматизированную сборку и доставку для всех основных платформ.

Простая установка с помощью yum и apt


Новая версия работает на большинстве ОС семейства Linux Fedora, Red Hat, Elementary, Debian и многих других. Разработчики постарались подготовить все необходимые открытые репозитории для лёгкого доступа к утилите. Установить rdiff-backup можно с помощью менеджера пакетов или пошаговой инструкции на GitHub-странице проекта.

Новый дом


Сайт проекта переехал с Savannah на GitHub Pages (rdiff-backup.net), разработчики обновили контент и дизайн сайта.

Как работать с rdiff-backup


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

Бэкап


Чтобы запустить бэкап на локальном диске (например, USB), введите команду rdiff-backup, затем имя источника (откуда будете копировать файлы) и путь к каталогу, в который вы планируете сохранить их.

Например, чтобы сделать бэкап на локальном диске с именем my_backup_drive, введите:

$ rdiff-backup /home/tux/ /run/media/tux/my_backup_drive/

Для сохранения файлов во внешнем хранилище введите путь к удалённому серверу вместе со знаком ::

$ rdiff-backup /home/tux/ tux@example.com::/my_backup_drive/

Вероятно, ещё вам потребуются SSH ключи для доступа на сервер.

Восстановление файлов из бэкапа


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

Тут нам на помощь придут команды копирования cp для локального диска и scp для удалённого сервера.

Для локального диска нужно написать, например, такое:

$ cp _run_media/tux/my_backup_drive/Documents/example.txt \ ~/Documents

Для удалённого сервера:

$ scp tux@example.com::/my_backup_drive/Documents/example.txt \ ~/Documents

У команды rdiff-backup есть опции, которые позволяют настроить параметры копирования. Например, --restore-as-of даёт возможность указать, какую версию файла нужно восстановить.

Допустим, вы хотите восстановить файл в том состоянии, в котором он был 4 дня назад:

$ rdiff-backup --restore-as-of 4D \ /run/media/tux/foo.txt ~/foo_4D.txt

Или, может быть, вам нужна последняя версия:

$ rdiff-backup --restore-as-of now \ /run/media/tux/foo.txt ~/foo_4D.txt

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



На правах рекламы


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

Подробнее..

Опенсорсные альтернативы Google Analytics на своём хостинге

08.09.2020 14:23:50 | Автор: admin

Веб-интерфейс опенсорсного сервиса аналитики Matomo

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

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

К счастью, есть ряд свободных, опенсорсных альтернатив Google Analytics, которые к тому же работают быстрее, поскольку скрипты меньше по размеру и загружаются с вашего собственного хостинга, а не со стороннего сервера. Информация о пользователях никуда не отправляется, а многие сервисы не используют куки и соответствуют законодательству GDPR о защите личных данных.

Начнём с самого свежего. Инструмент Umami запустили несколько недель назад в августе 2020 года.

Umami


Это программа с открытым исходным кодом, которую выпустил разработчик из Adobe Майк Цао. Он искал более простую и быструю альтернативу Google Analytics для своих веб-сайтов и в итоге просто разработал собственное решение.

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

git clone https://github.com/mikecao/umami.gitcd umaminpm install

Umami выдаёт статистику по просмотрам всех/конкретных страниц, по браузерам, ОС, рефереррам, устройствам и странам. Показано количество посетителей и просмотров, bounce rate и среднее время визита за сутки, неделю, месяц. Многим большего и не надо.

Скрипт Umami срабатывает практически мгновенно, а полная статистика выводится на одну страницу. Образец такой страницы:



Одно из преимуществ своего хостинга возможность обойти некоторые правила блокировщиков рекламы, которые запрещают загружать скрипты со сторонних сайтов. Кроме того, значительно ускоряется загрузка веб-страницы: скрипт Umami очень маленький (всего 6 КБ). Код для вставки:



Кроме базовой функциональности, Umami настраивается на отслеживание произвольных событий, например, нажатия определённой кнопки. Скажем, у нас есть такая кнопка:

<button class="button">Sign up</button>

создаём новый класс:

umami--<event>--<event-name>

и прописываем этот класс для кнопки:

<button class="button umami--click--signup-button">Sign up</button>

Статистика по трём кнопкам на сайте:



Все данные, записанные инструментом, анонимизируются и хранятся в базе данных MySQL или PostgreSQL. Для работы нужен Node.js 10.13+.

Исходный код опубликован под свободной лицензией MIT, его можно посмотреть в репозитории на GitHub.

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

Matomo (Piwik)


Если вас по каким-то причинам не устраивает Umami, можно испытать другие опенсорсные системы. Одна из самых известных Matomo (бывшая Piwik).



У Matomo гораздо более богатая функциональность, чем у Umami. Например, здесь есть импорт данных из Google Analytics, отчёты по скорости генерации отдельных страниц, уведомления по почте/SMS в случае наступления указанных событий, трекинг контента, отдельный модуль аналитики для интернет-магазинов и многое другое. Интерфейс панели со статистикой более гибко настраивается с помощью виджетов.


Виджеты для настройки главного экрана Matomo

Кроме версии на собственном хостинге, предлагается платная версия Matomo Cloud.

Matomo прямо позиционирует себя как безопасную альтернативу Google Analytics, а компания в своём блоге периодически публикует новости о юридических претензиях к Google в связи с отправкой данных о пользователях в США, что потенциально противоречит GDPR.

Даже бесплатная версия обладает большей функциональностью, чем Umami, а платный пакет Premium Bundle предлагает дополнительную функциональность, в том числе теплокарты, записи сессий, настраиваемые отчёты, A/B-тестирование, туннели конверсии, SEO-статистику по ключевым словам, аудит логов и т. д. Сравнение бесплатной версии, платных функций и облачной версии см. здесь.

Plausible Analytics


Ещё один опенсорсный инструмент. Код программы в открытом доступе, ничто не мешает взять его и установить на своём сервере, хотя компания активно продвигает облачную версию стоимостью от $6 в месяц (это минимальная цена для сайтов с трафиком менее 10 тыс. посетителей в месяц).



В отличие от Matomo, опенсорсная версия Plausible ничем не отличается от платной облачной версии по функциям.

Plausible тоже позиционирует себя как свободная и безопасная альтернатива Google Analytics, которая не использует куки и полностью соответствует GDPR.

Ограниченную функциональность можно рассматривать как преимущество. В самом деле, большинство функций Google Analytics требуется крайне небольшому количеству владельцев сайтов, но за них мы вынуждены платить приватностью своих пользователей, юридическими рисками и более медленной работой сайтов. Скрипты Google Analytics грузятся со сторонних серверов, добавляя задержку к загрузке страницы. Кроме того, они сами по себе объёмные (два скрипта в сумме 45,7 КБ) и требуют времени на выполнение на стороне клиента. Для сравнения, вот размеры скриптов Google Analytics и опенсорсных платформ из этого обзора:

Инструмент Скрипт Размер
Google Tag Manager googletagmanager.com/gtag/js 28 КБ
Google Analytics google-analytics.com/analytics.js 17,7 КБ
Umami umami.js 6 КБ
Matomo matomo.js 22,8 КБ
Plausible Analytics plausible.io/js/plausible.js <1 КБ

Огромные размеры скриптов Google Analytics объясняются тем, что инструмент отслеживает сотни метрик для более 125 разнообразных отчётов.

Plausible Analytics самый аскетичный вариант. Это инструмент для тех, кому достаточно минимальной статистики. Даже немного странно, что с такой скромной функциональностью компания предлагает продвинутые тарифные планы для корпораций по $150 в месяц.

Демо-страница Plausible.

Другие опенсорсные инструменты


Другие опенсорсные инструменты похожей функциональности:


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


Демо GoAccess

GoAccess тоже опенсорсная программа. Репозиторий. Демо.



Конечно, перечисленные инструменты нельзя назвать полноценной заменой системы Google Analytics, которая работает в фирменной парадигме Acquisition/Behavior/Conversion. Но опенсорсные скрипты на собственном хостинге действительно хорошая альтернатива во многих случаях.

P. S. По статистике W3Tech за сентябрь 2020 года, скрипты Google Analytics установлены на 55,3% сайтов в интернете. У самого популярного опенсорсного инструмента аналитики всего 1%.

2019
01.09
2019
01.10
2019
01.11
2019
01.12
2020
01.01
2020
01.02
2020
01.03
2020
01.04
2020
01.05
2020
01.06
2020
01.07
2020
01.08
2020
01.09
Нет 34,1% 34,5% 34,9% 34,9% 34,9% 35,1% 35,2% 36,1% 36,2% 35,1% 34,7% 34,7% 34,3%
Google Analytics 56,3% 55,9% 55,5% 55,5% 55,4% 55,1% 55,0% 53,8% 53,6% 54,6% 55,0% 55,0% 55,3%
Facebook Pixel 8,5% 8,5% 8,5% 8,7% 8,9% 8,9% 9,1% 9,0% 9,0% 9,3% 9,4% 9,5% 9,7%
Yandex.Metrica 5,8% 5,8% 5,9% 6,1% 6,5% 6,7% 6,9% 7,0% 7,2% 7,3% 7,4% 7,4% 7,4%
WordPress Jetpack 4,8% 4,7% 4,7% 4,7% 4,6% 4,6% 4,6% 4,6% 4,6% 4,7% 4,8% 4,8% 4,8%
Hotjar 2,7% 2,7% 2,7% 2,7% 2,8% 2,8% 2,8% 2,8% 2,8% 2,9% 2,9% 2,9% 2,9%
LiveInternet 2,3% 2,2% 2,2% 2,3% 2,4% 2,5% 2,5% 2,5% 2,5% 2,6% 2,6% 2,5% 2,5%
New Relic 1,5% 1,4% 1,4% 1,4% 1,4% 1,4% 1,5% 1,5% 1,4% 1,4% 1,3% 1,3% 1,3%
Matomo 1,1% 1,1% 1,1% 1,1% 1,1% 1,1% 1,0% 1,0% 0,9% 1,0% 1,0% 1,0% 1,0%
Top.Mail.Ru 0,8% 0,8% 0,8% 0,9% 0,9% 0,9% 0,9% 0,9% 1,0% 1,0% 1,0% 1,0% 1,0%

Доля Google Analytics вроде бы стала снижаться в начале 2020 года, но сейчас снова растёт.



На правах рекламы


Надёжный и недорогой VDS от VDSina позволит разместить любой проект всё будет работать без сбоев и с высоким uptime!

Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru