Beget Хостинг

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

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

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

Со временем сервисов в нашей системе стало появляться все больше: стали регистратором доменов — выносим регистрацию в отдельный сервис; метрик с серверов стало очень много — пишем сервис, который делает выборки из ClickHouse / InfluxDB; Нужно сделать эмулятор запуска задач «как через Crontab»; для пользователей — пишем сервис. Наверное, это многим будет знакомо.

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


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

Ах, да… еще ведь документация нужна. Иначе в чатиках происходят такие диалоги:
— Ребят, как мне получить баланс пользователя из биллинга?
— Сделай вызов в billing/getBalance(customerId)
— А список услуг как получить?
— Не помню, поищи нужный контроллер в
Короче говоря, зародилась мечта о волшебном едином стандарте и технологии для создания сетевых API, которые решат все проблемы и сэкономят нам вагон времени.

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

• Используемый способ описания API должен быть декларативным
• Результат должен быть однозначным и человеко-понятным: нужно проводить code review
• Нужна возможность описывать как успешный flow, так и ошибки. Причем это должно делаться явно для каждого метода
• На основе описания нужно генерировать как можно больше скучного кода для клиента и сервера

Из коробки он удовлетворял почти всем нашим требованиям. Если в двух словах:

• Декларативное описание методов и структур данных
• Он очень читабельный и простой. По получившимся .proto-файлам легко проводить code review. Синтаксис IDL близок к популярным ЯП
• Завезены генераторы под большинство популярных ЯП (но есть нюанс. О нем ниже)
• gRPC — просто механизм RPC без каких-либо строгих требований к организации API. Это дает возможность разработать собственные принципы и гайдлайны с учетом накопленного опыта

Однако, идеальных технологий не существует. Для нас возникло несколько камней преткновения:

• Мы активно используем PHP и он не умеет в сервер gRPC;
• Наш фронтенд по-прежнему ожидает привычный HTTP. На текущий момент мы были вынуждены «проксировать» запросы фронтенда через отдельное приложение, формирующее правильные запросы к внутреннему API. В подавляющем большинстве случаев это лишняя скучная работа. Хотелось бы внутри нашей системы все отдавать через один протокол с автоматической конвертацией в HTTP для фронтенда.

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

И так далее, много технической информации
Надеюсь на Хабре топик не удалится, т.к. сохранять для Истории рынка не вижу смысла, черзе 5 лет устареет все. Просто запомним факт, что была такая новость ;)
habr.com/company/beget/blog/348008/

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

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



Почему мы стали регистратором и чем руководствовались
До того, как мы получили аккредитацию, мы регистрировали домены .RU/.РФ через разных регистраторов: основным поставщиком были reg.ru, также мы работали с r01 и nic.ru. Часть наших доменов до сих пор находится на обслуживании у названных регистраторов. Кроме того, мы работаем с названными регистраторами по доменам в отличных от .RU/.РФ зонах. Если клиент хотел передать нам домен на обслуживание, мы шли ему навстречу и переносили его в наш личный кабинет текущего регистратора домена.

Это создавало большое количество проблем как для нас, так и для наших клиентов. Были случаи разделегирования доменов, о которых нам приходилось узнавать от клиентов, ошибок со стороны программного обеспечения регистраторов. Сама поддержка трех разных API создавала трудности. Что касается цен на домены, то наши партнерские цены были всего примерно на 10% выше той цены, что выставлял Координационный центр, поэтому это не являлось основной причиной для становления самостоятельным регистратором…

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

Первая попытка подать заявку на аккредитацию была летом 2014 года, но тогда, к сожалению, в связи с другими делами (в тот момент мы активно планировали выход на международный рынок, впереди еще будет вторая попытка =), папка с документами так и осталась просто папкой с названием «Регистратор-проект».

Второй раз мы решили стать регистратором в зонах .RU/.РФ в начале 2016 года, когда появилась информация о том, что перенос доменов между регистраторами станет безбумажным. Безусловно, мы были крайне разочарованы тем, что, в отличие от международных зон, наш координационный центр национальных доменов не стал придерживаться той же схемы работы, и деньги берутся только за перенос, а не за продление в момент переноса (что явно не способствует либерализации рынка). Можно сказать, что так сделать было нельзя в связи с тем, что максимальный срок регистрации домена в зонах .RU/.РФ составляет 1 год, но что мешает сделать его больше?

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

Что нужно сделать, чтобы получить аккредитацию
Доменные зоны .RU/.РФ регулирует Координационный центр национального домена сети интернет (https://cctld.ru/).

На текущий момент аккредитовано 46 регистраторов (https://cctld.ru/ru/registrators/), и примечательно, что 13 из них, включая нас, были аккредитованы в прошлом году. Отдельно хочется поздравить наших коллег из сферы хостинга, которые получили аккредитацию совсем недавно — это шаг в правильном направлении. Возможно, другие компании, как и мы, решили сделать это связи с изменением политики переноса доменов между регистраторами.

Всю информацию о том, как получить аккредитацию, можно и нужно искать на их сайте — cctld.ru/ru/docs/

Читаем требования к будущему регистратору и соответствуем им.
Получить аккредитацию может юридическое лицо РФ, имеющее рабочий офис и минимальное количество сотрудников для обеспечения работы в качестве регистратора. Необходимо будет доказать (подтвердить) координационному центру стабильное финансовое положение, возможность обеспечить устойчивость работы ПО при работе с Реестром и резервное копирование данных.
А также: застраховать деятельность в качестве регистратора и подготовить прототип сайта, на котором будет приведена вся информация относительно будущей работы в качестве регистратора.
cctld.ru/ru/docs/project/accr_treb_21042014.pdf

1. Регистратор обязан:
…
1.3. своевременно страховать профессиональную ответственность, связанную с деятельностью по регистрации доменных имен:
1.3.1. для Регистраторов со стажем аккредитации не менее 1 (одного) года — на сумму не менее 15 000 000 (пятнадцати миллионов) рублей или 500 000 (пятисот тысяч) долларов США;
1.3.2. для вновь аккредитуемой организации — на сумму не менее 30 000 000 (тридцати миллионов) рублей или предоставить доказательство намерений осуществить такое страхование в срок не более 1 (одного) месяца с даты получения аккредитации;

Этот пункт может вызвать трудности, так как если просто обратиться в любую страховую компанию с вопросов страхования деятельности в качестве регистратора, это вызывает некоторое замешательство у страховщиков. Поэтому тут все-таки желательно попасть на того специалиста, который уже оформлял подобную страховку. Если самостоятельно разобраться с этим вопросом не получится, пишите на manager@beget.com, подскажем контакты. Стоимость страховки на момент аккредитации составила около 30 тыс. руб.

1.6. соответствовать требованиям, изложенным во вступивших в силу Технических условиях взаимодействия с системой регистрации доменов (далее – «Технические условия»). Вновь аккредитуемая организация должна пройти технические испытания на соответствие Техническим условиям в течение 1 (одного) года после принятия решения о ее аккредитации. До момента успешного прохождения технических испытаний вновь аккредитуемой организации не будет предоставлен доступ к Реестрам доменных имен, за исключением доступа к тестовому Реестру в порядке, установленном Положением о технических испытаниях

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

2. для оказания услуг регистрации доменных имен Регистратор обязан располагать необходимым количеством квалифицированных работников для выполнения следующих функций:
− административные вопросы;
− финансовые вопросы;
− технические вопросы;
− взаимодействие с пользователями и администраторами;
− защита информации;
− юридические вопросы;
− взаимодействие с правоохранительными органами.

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

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

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

По этому пункту необходимо будет подготовить прототип сайта с содержанием всей информации о вас, образцами заявлений и описанием всех возможных действий с доменами. Подготовка сайта, безусловно, займет время, но задача не слишком сложная, учитывая тот факт, что всю информацию о действиях с доменами можно посмотреть, к примеру, на нашем сайте beget.com/ru/domain-register

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

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

Пример регламента:
Регламент действий в нештатных ситуациях

Регламент процесса регистрации/продления

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

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

Заполняем анкету и готовим пакет документов


Если вы чувствуете силы и возможности для соответствия всем описанным требованиям, нужно открыть Соглашение об аккредитации (https://cctld.ru/ru/docs/project/accr_polo_21042014.pdf), найти пункт 2 и подготовить пакет документов в точном соответствии с приведенным списком, после чего отправить его на почтовый адрес Координационного центра.
Если формально все признаки соблюдены и документы соответствуют приведенному списку, то Координационный центр в течение 3-х дней после получения пакета документов вышлет вам счет на аккредитацию. На день получения нами аккредитации стоимость проверки вашей компетенции осуществлять регистрацию доменных имен составила 80000 руб. Данная сумма не возвращается, даже если Координационный центр даст Вам отказ в аккредитации.

• Оплачиваем счет за проверку на аккредитацию.
• Ждем проверки документов и соответствия всем требованиям.

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

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

Получаем решение об аккредитации или отказ


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

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

Для работы с Реестром можно написать собственное решение или же использовать ПО от АО «Технический центр Интернет» под названием «Виртуальный регистратор». Подробнее о Виртуальном регистраторе можно прочесть здесь. «Виртуальный регистратор» − платный продукт, и за его использование необходимо платить от 22 руб. за каждую регистрацию домена, либо 10000 руб./мес. за безлимитный тариф.

Рады сообщить, что мы получили аккредитацию международного регистратора ICANN и были включены в список аккредитованных регистраторов!
www.icann.org/registrar-reports/accredited-list.html

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



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


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

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

lg.beget.com

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

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

12.03.2018 г. изменяются условия предоставления услуг виртуального и VIP-хостинга. Изменения коснулись увеличения дискового пространства и ценовой политики. В зависимости от тарифного плана увеличение дискового пространства составило от 1 до 15 Гб. Мы также добавили возможность оплатить хостинг на 2 года с еще большей скидкой.



Новые условия вступают в силу 12 марта 2018 года в 00:00 часов по МСК, но для всех наших клиентов, оплативших услуги до 12.03.2018 г., новые условия предоставления услуг вступают в силу только после окончания оплаченного периода.

Black Friday в Beget: домены за 57 рублей!
С 24 по 26 ноября мы предоставляем вам 70% скидку на покупку доменов в зонах .ru/.рф!
Домен за 57 рублей — успей зарегистрировать!
cp.beget.com/login?next=/domains

Технология сессии в PHP являются простым способом хранения информации для отдельно взятого пользователя сайта. Например: товары, добавленные в корзину магазина, настройки уведомлений и т.д. При первом запросе сайта к серверу, в браузере сохраняется в cookies уникальный идентификатор сессии пользователя. Затем идентификатор или связка идентификатора с IP адресом идентифицирует пользователя. Это может использоваться для сохранения состояния между запросами страниц. Идентификаторы сессий обычно отправляются браузеру через сессионный Cookie и используются для получения имеющихся данных сессии.

Сессии используют простую технологию: PHP будет либо получать данные существующей сессии, используя переданный идентификатор (обычно из сессионного cookie), или, если ничего не передавалось, будет создана новая сессия. PHP заполнит суперглобальную переменную $_SESSION сессионной информацией после того, как будет запущена сессия. Когда PHP завершает работу, он автоматически сериализует содержимое суперглобальной переменной $_SESSION и отправляет для сохранения, используя сессионный обработчик для записи сессии.

По умолчанию PHP использует внутренний обработчик files для сохранения сессий, который установлен в INI-переменной session.save_handler. Этот обработчик сохраняет данные на сервере в директории, указанной в конфигурационной директиве session.save_path.

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

<?php
 
session_start();
if (!isset($_SESSION['count'])) {
    $_SESSION['count'] = 0;
} else {
    $_SESSION['count']++;
}
 
echo $_SESSION['count'];

beget.com/ru/articles/redis_session

4 марта после прохождения технических испытаний приступил к работе аккредитованный регистратор российских доменов — ООО «Бегет» из Санкт-Петербурга.
Соглашение об аккредитации в доменах .RU и.РФ с ООО «Бегет» было подписано 21 октября 2016 года. Это четвертый аккредитованный регистратор российских доменов из Северной столицы. Всего на российском доменном рынке аккредитовано 45 регистраторов.
cctld.ru/ru/press_center/news/news_detail.php?ID=11403

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

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

Описание программы
Для участия в программе принимаются уязвимости/ошибки в работе панели управления хостингом cp.beget.com, а также любые способы получения данных, располагающихся на хостинговых серверах. Текущие цены за найденные уязвимости актуальны до 15 апреля 2017 года.

Выплаты и размеры наград
Вознаграждение выплачивается в том случае, если Вы первый, кто сообщил о данной уязвимости, если вы не использовали её для причинения вреда нашей инфраструктуре или пользователям и не публиковали данные об этой уязвимости. До 15 апреля 2017 года предусмотрен следующий уровень вознаграждения за найденные уязвимости:
Получение доступа с правами пользователя root на хостинговом сервере — 150 000 рублей.
Получение доступа с правами пользователя root на системном сервере (серверы, где непосредственно не располагаются данные пользователей) — 200 000 рублей.
Получение доступа к БД с системной информацией — 50 000 рублей.
За возможность навредить другому пользователю (кроме XSS) или получить доступ к его данным — от 1000 до 50 000 рублей. В данном случае подразумеваются способы причинить вред или получить доступ данным другого пользователя хостинга через панель управления хостингом или через другие аккаунты на сервере.

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

Взаимодействие по найденным уязвимостям
Необходимо отправить отчет о найденной уязвимости по адресу bugbounty@beget.com или через тикет систему панели управления хостингом.

В отчете должно содержаться:

• Подробное описание найденной уязвимости
• Худший сценарий её использования (желательно)
• Подробное и понятное описание шагов, необходимых для воспроизведения найденной уязвимости или рабочее подтверждение своей концепции

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