Подарки и скидки до 50% в честь 11-летия компании
Сегодня компании Friendhosting LTD исполняется 11 лет. По современным меркам интернета 11 лет это не просто длительный период времени, это целая жизнь. Мы испытываем одновременно радость и гордость, идя по этой жизни вместе с вами.
Нам очень приятно видеть какую популярность за это время получили наши услуги в IT сообществе, как вы цените стабильную работу серверов и нашу круглосуточную дружелюбную техническую поддержку. Разумеется, это не было бы возможным без вас, наши дорогие друзья – клиенты, коллеги и партнеры. Большое вам спасибо!
В честь дня рождения компании мы приготовили для вас следующие скидки и бонусы, которые будут действовать с 20.04.2020 до 20.05.2020.
friendhosting.net/promo/11year.php

1. «Скидка 50%». Экономьте до 50% при заказе нового vds или виртуального хостинга на срок от одного до шести месяцев. Для получения скидки во время заказа используйте промо-код 11year
friendhosting.net/virtual-hosting.php
friendhosting.net/vps.php

2. «Плюс 100%». Мы увеличим оплаченный период любого нового заказа vds или виртуального хостинга, сделанного во время акции, в два раза (максимальное количество бонусных месяцев — 6). Для получения бонуса необходимо создать запрос в финансовый отдел после оплаты заказа.

3. «Старый друг лучше новых двух». Что может быть лучше, чем увидеть старого друга в свой день рождения? Для вас, старые друзья, мы приготовили следующие подарки:

• увеличение оплаченного периода vds или виртуального хостинга в два раза (максимальное количество бонусных месяцев — 6);
• восстановление скидки по программе лояльности 15% для каждого сделанного заказа в период проведения акции.

Условия акции «Старый друг лучше новых двух»:

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

4. Бонус за продление VDS. Уже есть заказ VDS? Продлите его на длительный период и получите бонус. Если во время проведения акции Вы продлите vds на:

• 6 месяцев, то получите в подарок 1 месяц оплаченного периода. Скидка в 5% за продление на 6 месяцев и скидка по программе лояльности до 25% будут учтены автоматически;
• 12 месяцев, то получите в подарок 2 месяца оплаченного периода. Скидка в 10% за продление на 6 месяцев и скидка по программе лояльности до 25% будут учтены автоматически;

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

• Акция проходит с 20.04.2020 по 20.05.2020 года включительно.
• Внимание! Скидки и бонусы НЕ могут суммироваться.

https://my.friendhosting.net

Акселерационные программы Yandex Cloud Boost и NVIDIA Inception договорились о взаимной поддержке для своих участников. С апреля 2020 года компании-разработчики в области искусственного интеллекта из NVIDIA Inception могут присоединиться к Cloud Boost по упрощенной процедуре. В свою очередь, ИИ-стартапы Cloud Boost получают доступ к ресурсам NVIDIA Inception на приоритетных условиях.

Что получает компания-участник NVIDIA Inception, присоединившись к программе Yandex Cloud Boost

• Грант от 200 000 руб. (с НДС) на тестирование и использование инфраструктурных сервисов и сервисов Data Storage & Analytics, Cloud-Native, ML & AI: при этом половину гранта, а не четверть, как это предусмотрено стандартными условиями программы, можно потратить на ресурсы с GPU;
• помощь архитекторов в развертывании инфраструктуры на платформе Яндекс.Облако;
• скидку 20% на год на сервисы Data Storage & Analytics и Cloud-Native;
• бесплатную техническую поддержку;
• доступ к закрытому тестированию новых сервисов;
• содействие в продвижении продукта.

Что получает стартап в Yandex Cloud Boost, присоединившись к NVIDIA Inception

• доступ к технологиям: программным инструментам, отдельным графическим процессорам NVIDIA и вычислительным системам линейки NVIDIA DGX;
• бесплатный доступ ко всем онлайн-курсам в Институте глубокого обучения NVIDIA;
• рекомендации по выбору приложений и оборудования на GPU;
• специальные цены на оборудование;
• маркетинговую поддержку.

Для кого это предложение
Специальное предложение от Yandex Cloud Boost и NVIDIA Inception ориентировано на компании, которые ведут работы в области изучения и применения искусственного интеллекта. Теперь сотни стартапов-участников акселерационных программ получат доступ к ресурсам и сервисам для полноценного тестирования AI-проекта.

Как стартапу воспользоваться специальным предложением от Yandex Cloud Boost и NVIDIA Inception
Компании-участнику NVIDIA Inception необходимо заполнить заявку на сайте Yandex Cloud Boost, указав в комментариях кодовое слово «NVIDIA».

Компании-участнику Yandex Cloud Boost нужно оставить заявку на странице NVIDIA Inception, в разделе «Which accelerators/incubators are you currently part or have you been part of?» указав программу Yandex Cloud Boost.

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

По всем вопросам, связанным с данным предложением, просьба обращаться к Марине Поликарповой: marinapolik@yandex-team.ru

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

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




x5x.ru/vps.html

Платформа Яндекс.Облако открывает доступ к инструменту для работы с данными по распространению коронавируса в России и мире.

С помощью технологии Yandex DataLens мы собрали в единую информационно-аналитическую панель (дашборд) информацию из трёх источников:

• Роспотребнадзор: статистика о количестве заражений, выздоровлений и летальных исходов в России;
• Университет Джонса Хопкинса: аналогичные данные по всему миру;
• данные сервисов Яндекса: индекс самоизоляции.

Yandex DataLens позволяет гибко работать с данными: загружать, объединять, мгновенно делать наглядные визуализации — графики, диаграммы, таблицы, а также накладывать показатели на карту. В дополнение к данным, которые предоставляет Яндекс.Облако, пользователи могут подключать собственные источники. Полученными результатами можно делиться с коллегами и публиковать их в открытом доступе на любых внешних ресурсах. Все данные обновляются в режиме реального времени: как только новая информация появляется в источниках, она становится доступна в Yandex DataLens.


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

Изучить публичный дашборд можно по ссылке datalens.yandex/covid19

Если вы хотите сохранить себе копию дашборда, изменить её, создать собственные визуализации или дополнить своими данными — нужно завести учётную запись в Yandex DataLens и импортировать пресет из маркетплейса.


Для работы с этим пресетом достаточно бесплатного тарифа Yandex DataLens.

В Облаке появился сервис, который сделает управление TLS-сертификатами удобнее. С его помощью вы можете получать новые TLS-сертификаты от Let’s Encrypt, добавлять свои сертификаты и использовать их при создании безопасных подключений к статическим сайтам в Облаке.

Let’s Encrypt предоставляет Domain Validation (DV) TLS-сертификаты со сроком действия 90 дней. Такие сертификаты подтверждают, что домен принадлежит заявителю. Если вам нужны сертификаты Organization Validation (OV) или Extended Validation (EV), вы можете получить их в стороннем центре сертификации и загрузить в Certificate Manager.

Certificate Manager, управляет сертификатами от Let’s Encrypt и автоматически запросит их обновление за 30 дней до окончания срока действия. Вам необходимо только подтвердить права на домены, и все ресурсы Облака, которые используют сертификат, получат его новую версию.

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

Certificate Manager находится на стадии Preview. Запросить доступ к сервису можно через форму заявки на странице сервиса или в консоли управления.

Процессор 4,5 ГГц — оптимально для игр и софта требовательного к мощности проца.
По неприлично низкой цене и не спрашивайте как у нас так получается!


https://vdsina.ru

Как вы, возможно, знаете, наши предложения и технологии VPS постоянно развиваются. По этой причине мы приняли решение прекратить использование старых услуг VPS Classic 2014 с 30 апреля 2020 года.

Чтобы предвидеть прекращение предоставления вам услуг VPS Classic 2014, мы настоятельно рекомендуем вам восстановить все ваши данные до этой даты. Обратите внимание, что функция автоматической миграции недоступна.

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

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

• войдите в свою клиентскую зону OVHcloud;
• выберите одно из наших предложений VPS;
• введите свой промокод;
• создайте резервную копию ваших данных и перенесите их вручную;
• проверьте, правильно ли работает ваш новый VPS;
• отмените свое старое предложение VPS 2014

Еще раз мы хотели бы поблагодарить вас за доверие к нам.
Команда OVHcloud

Последнее время мы делаем общий процессор как на Ryzen-7 на 16 долей, так и на EPYC 7502P на 32 доли и даже i9-9900k на 8 долей делаем.

• У Рузен-7 16 потока — 16 долей — все идеально 128 озу и диска достаточно
• У Эпика — 64 потока — 32 доли ибо 256 озу, 128 цена уже не выгодна
• У 9900k — 16 потока, но мало диска для 2020, поэтому 8 долей, можно было сделать как в 2017, но я любитель моды, поэтому лучше 8 но современно.

Но меня все равно просят сделать "по старинке" что-то. Например многим очень нравились тарифы по 500р которые были i7-6700k 1vCore / 4 / 25 SSD — 500р
Там было 8 потоков, но 16 долей :) т.е. 25% от ядра наверно на долю, хотя мы до сих пор не знаем как именно VMmanager панель все это делит.

1. Но делать за 500р — в 2020 у меня желания нет.
2. Поэтому я решил сделать так.
3. EPYC 7502P — 32 честных ядра и 64 потока.
4. Сделать там 128 озу минимальное и купить самый дешевый диск 960 NVME. Короче максимально в дешевизну пойти.
5. Типо нету общих ядер, а цена 1500р оправдывается тем что выделяется 4 ядра вместо 1.

И получилось вот так.

• EPYC 7502P [Rome-Zen2] [4 Core] / 8 ddr4 / 50 ГБ NVME — 1500р
• EPYC 7502P [Rome-Zen2] [8 Core] / 16 ddr4 / 100 ГБ NVME — 3000р
• EPYC 7502P [Rome-Zen2] [12 Core] / 24 ddr4 / 150 ГБ NVME — 4500р
• EPYC 7502P [Rome-Zen2] [16 Core] / 32 ddr4 / 200 ГБ NVME — 6000р
• EPYC 7502P [Rome-Zen2] [32 Core] / 64 ddr4 / 400 ГБ NVME — 12000р

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

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

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

В этом руководстве мы увидим, как распределять трафик между серверами приложений, предоставляя высокодоступный балансировщик нагрузки в Hetzner Cloud, используя такие инструменты, как haproxy, keepalived и Ansible:

• haproxy будет выполнять тяжелую работу по фактическому распределению трафика между несколькими бэкэндами; он очень производительный и эффективный, и позволяет нам распределять трафик для нескольких отдельных приложений одновременно; haproxy будет непрерывно пропинговать серверы бэкэнда и гарантировать, что трафик отправляется только в исправные бэкэнды;
• keepalived позаботится о том, чтобы один сервер балансировки нагрузки (главный или резервный) всегда был готов к приему трафика; для этого мы будем использовать Hetzner Cloud CLI, удобный инструмент, который мы можем использовать для косвенного взаимодействия с Hetzner Cloud API, чтобы назначать плавающий IP-адрес как главному серверу, так и серверу резервного копирования, в зависимости от состояния каждого; плавающий IP-адрес — это просто IP-адрес, который может быть «перемещен» с сервера на другой по мере необходимости, и это может быть легко автоматизировано. Это особенно важно для балансировщика нагрузки, поскольку мы можем использовать этот IP-адрес в конфигурации DNS для наших доменов, чтобы избежать таких проблем, как кэширование и распространение записей DNS при возникновении сбоя; под «состоянием сервера» мы имеем в виду, работает ли haproxy; если главный сервер выйдет из строя, haproxy будет рассматриваться как недоступный и, следовательно, поддерживающий активность — благодаря постоянной связи между главным и резервным сервером — даст команду серверу резервного копирования вступить во владение и назначит плавающие IP-адреса себе;
• Ansible — очень популярный инструмент управления конфигурацией, который мы можем использовать для автоматизации всего процесса, а не для настройки всего этого вручную. Это обеспечивает быструю и повторяемую подготовку нескольких балансировщиков нагрузки.

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

• учетная запись Hetzner Cloud и базовое понимание того, как создавать ресурсы в проекте, такие как серверы и плавающие IP-адреса; мы будем использовать вышеупомянутый инструмент CLI для создания этих ресурсов, но вы можете использовать веб-консоль Hetzner Cloud, если хотите;
• проект, в котором будут размещены ваши серверы и плавающие IP-адреса;
• токен, необходимый для назначения плавающих IP-адресов с помощью CLI; Вы можете создать его в консоли Hetzner Cloud в проекте, в Access> API tokens. Запишите этот токен где-нибудь, как менеджер паролей, потому что вы увидите его только один раз;
• Ansible установлен на вашем компьютере — пожалуйста, обратитесь к инструкциям здесь для вашей операционной системы;
• установлен Python (Ansible написан на Python);
• модуль Python hcloud-python. Ansible имеет встроенную поддержку Hetzner Cloud, но для его работы требуется этот модуль. Мы будем использовать это для реализации динамического инвентаризации, чтобы Ansible мог напрямую запросить Hetzner Cloud, чтобы найти хосты.

community.hetzner.com/tutorials/howto-highly-available-load-balancer-hetzner-cloud-ansible

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

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

От корпоративного Jabber к Slack
Давным-давно в далекой-далекой галактике, когда в Selectel работало не более 50 сотрудников — каждый использовал для коммуникации разные средства. На тот момент ICQ еще на потеряла актуальность, кто-то зависал в IRC, а кто-то вообще использовал e-mail как основной способ обмена данными. Чтобы привести коммуникации внутри компании к единому стандарту и обеспечить безопасность требовался общий корпоративный мессенджер. По многим причинам, на тот момент, Jabber показался наиболее подходящим:

• Возможность общения в «комнатах» (аля IRC).
• Шифрование сообщений с помощью PGP/GPG.
• Поддержка истории сообщений.
• Обмен файлами.
• Крайне низкие требования к серверной инфраструктуре.
• Возможность инкапсуляции той же ICQ, IRC, etc. внутрь XMPP-протокола.
• Большое количество приложений-клиентов под любые операционные системы.

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

• Высокий расход батареи на мобильных устройствах.
• Существенный трафик за счет избыточности (сжатие и шифрование одновременно не поддерживается — приходилось с этим мириться).
• Некоторые клиенты испытывали проблему с неверно выбранной кодировкой по-умолчанию (UTF-8 only).
• Обмен файлами требует прямой связности между двумя клиентами.
• XEP-0045 (Multi-User Chat Extension) — мрак и ужас (кто знает, тот поймет).

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

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

Чего мы хотели добиться? Любое событие от мониторинга или непосредственно от устройств должно «прилетать» прямо в мессенджер ответственному сотруднику или отделу. Обо всех инцидентах инфраструктуры должны быть мгновенно оповещены все сотрудники, чтобы действовать соответствующим образом.

Также крайне удобной функцией являлась интеграция с Google Docs. При совместной работе с документами Slack оповещает о сделанных изменениях и тем самым сразу обращает на них внимание. Впоследствии туда добавились и разнообразные боты, например, наш собственный HR-бот, позволяющий бронировать переговорные комнаты, узнавать даты выплаты заработной платы и даже просто поболтать с «искусственным интеллектом» (для особых интровертов).

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

От Slack к поиску альтернативы
Selectel продолжал активно расти и вот количество сотрудников перевалило за 350 человек. Все использовали Slack, однако, цена такого взаимодействия даже на самом недорогом тарифе с корпоративными функциями достигла немалой суммы в размере $38 000 за год. Наш рост не прекращался, а следовательно, встал вопрос — как можно сократить эти расходы? Так мы стали подыскивать альтернативу.

Бесплатные
Прежде всего наше внимание привлекла к себе платформа Zulip, являвшаяся основным средством корпоративной коммуникации в Dropbox. К слову сказать, именно Dropbox и выкупил Zulip в 2014 году, после чего опубликовал исходный код приложения на Github. Таким образом платформа стала доступна каждому под свободной лицензией Apache 2.0.

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

Вторым претендентом на приз стать нашим корпоративным мессенджером стал Rocket.Chat, выпущенный по лицензии MIT. Написанный на Java Script в связке с MongoDB мессенджер уже завоевал свою популярность среди профессионалов. По функциональным возможностям Rocket.Chat также очень схож со Slack: также позволяет создавать публичные каналы, закрытые группы и обсуждения, обмениваться файлами. Поддержка аудио- и видеосообщений есть, но эти функции работают не очень стабильно, поэтому у нас не используются. Работа над улучшением Rocket.Chat ведется постоянно, о чем свидетельствует множество коммитов на Github.

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

• невозможность открывать внутренние ссылки внутри клиента;
• отсутствие некоторых методов в REST API, например, обновления интеграции (добавить или удалить можно, а обновить нельзя);
• нестабильность работы Windows-клиента.

Помимо вышеперечисленных двух платформ мы также рассматривали кроссплатформенный мессенджер Riot.im. В нем используется протокол Matrix, разработанный в 2014 году как альтернатива существующим XMPP и IRC. Плюсом протокола является возможность использования «мостов» в такие популярные мессенджеры, как:

• Telegram;
• WhatsApp;
• Discord;
• ...

Однако, работа над серверной частью Synapse и клиентом Riot.im ведется не слишком активно (гораздо медленнее, чем над Rocket.Chat), что автоматически означает отсутствие оперативного устранения багов и необходимость доставать напильник.

Платные
Кроме бесплатных вариантов мы рассматривали и платные. В частности мы обратили внимание на одного из основных конкурентов Slack — Mattermost. Несмотря на наличие версии The Open Source Mattermost Team Edition — все нужные нам корпоративные функции доступны только в платных версиях.

Несмотря на заявления создателей Mattemost о том, что использование их мессенджера дешевле Slack — мы посчитали и пришли к выводу, что использование Mattermost обойдется нам дороже. Разумеется, такой вариант для нас не являлся приемлемым.

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

Подведение итогов
Посчитав все плюсы и минусы разных платформ, мы пришли к следующему выводу: «переезжать» на Rocket.Chat. В случае выявления серьезных проблем в работе запасным вариантом был выбран Zulip. После того как решение было одобрено руководством, началась подготовка инфраструктуры для развертывания.

Как осуществлялся переезд
Мы уже упоминали, что Rocket.Chat представляет собой серверное приложение, написанное на JavaScript и использующее MongoDB в качестве хранилища сообщений. Поэтому в первую очередь нам следовало обеспечить отказоустойчивость базы данных. MongoDB «из коробки» поддерживает аварийное переключение (Failover) при помощи механизма репликации, поэтому мы развернули 3 небольшие виртуальные машины в разных регионах (Москва и Санкт-Петербург) и настроили механизм Replica Set. Само по себе приложение архитектурно построено таким образом, что мы передаем ему данные обо всех репликах в наборе и оно само распределяет нагрузку между ними (с какой реплики читать и в какую писать).

Переходим к серверному приложению. Мы используем официальный Docker-образ Rocket.Chat, размещенный в DockerHub. Приложение развернуто в 3-х экземплярах на разных физических хостах и управляется с помощью Kubernetes. Нагрузка на поды (от англ. «pod» — стручок, капсула) балансируется также средствами Kubernetes, обеспечивая тем самым не только равномерность утилизации ресурсов, но и возможность производить обновления без остановки сервиса. В этом случае один из подов останавливается, корректно обрабатывая все активные подключения, и вместо него запускается новый под с обновленной версией образа приложения. Помимо легкости обновления, такой подход позволяет буквально в 1 клик масштабироваться горизонтально при возрастающей нагрузке.

Следует отметить, что Rocket.Chat имеет важную особенность. Все пересылаемые файлы экземпляр приложения по умолчанию хранит локально, а не в БД. Поэтому, когда требуется работа нескольких экземпляров приложения — нам потребовалось реализовать общее хранилище. Для этого мы воспользовались нашим S3-совместимым Облачным хранилищем, доступ к которому организовали для всех экземпляров приложения. Это позволило всем экземплярам приложения хранить файлы в едином месте, но это не стало потенциальной точкой отказа, ведь как мы уже упоминали в наших статьях — все данные, размещенные в облачном хранилище, реплицируются N+2.

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

Экспорт и импорт данных
Мы чаще всего рассказываем о том, как успешно решаем достаточно нетривиальные задачи, однако, при переезде нам так пока и не удалось корректно перенести историю сообщений из Slack в Rocket.Chat. Точная причина пока неизвестна, но предполагаем, что на момент переноса был баг, из-за которого файл экспорта был сформирован некорректно. Для нас это не было критичным, поскольку все сотрудники заранее были оповещены о «переезде» и самостоятельно сохранили важные для них данные. Так что, если планируете переезд — учитывайте, что на этапе импорта данных может возникнуть подобный «сюрприз».

Еще одним нюансом будут push-уведомления в мобильных приложениях. Дело в том, что сам Rocket.Chat по умолчанию использует свой собственный платный push-gateway. А это значит только одно — нужно либо консолидировать все push-уведомления на отдельном сервере, либо настраивать подключение сервера Rocket.Chat напрямую к серверам Google и Apple. В любом случае требуется самостоятельная подготовка мобильного приложения, путем добавления внутрь сертификатов и настроек.

Не менее важная часть переноса интеграций прошла на удивление проще. Оказалось, что достаточно всего лишь поменять Incoming Webhooks со Slack на Rocket.Chat и большая часть интеграций заработала корректно. Можем с уверенностью сказать о практически полной совместимости. Это сэкономило нам массу времени.

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

Заключение
Мы пока что используем Rocket.Chat недостаточно долго, чтобы однозначно сделать какие-то определенные выводы. Но первые же недели использования показали, что к новой платформе пользователи быстро привыкли и не испытывают серьезных проблем или трудностей. Через какое-то время мы еще раз вернемся к этой теме и расскажем о том — удалось ли нам решить проблему с импортом данных. Оставайтесь на связи!