sbercloud advanced что это
SberCloud – cloud services and technologies
SberCloud
Advanced
Пакетные решения для бизнеса
Наши продукты:
Cloud Container Engine
Сервис для автоматизации развёртывания, масштабирования и управления приложениями в высокопроизводительных кластерах Kubernetes
RDS for MySQL
Профессиональная платформа управления базами данных MySQL
FunctionGraph (serverless)
Сервис позволяет размещать и запускать код в бессерверной среде по заданному триггеру. Предоставляет мониторинг и журнал логов
API Gateway
Высокопроизводительный хостинг API. Упрощает публикацию, обслуживание, мониторинг, защиту и использование API в любых масштабах
Distributed Cache Service for Redis
Высокопроизводительный и простой в управлении распределенный сервис кэширования данных в памяти на базе Redis
Distributed Cache Service for Memcached
Высокопроизводительный и простой в управлении распределенный сервис кэширования данных в памяти на базе Memcached
SberCloud
Advanced
Пакетные решения для бизнеса
Наши клиенты:
SberCRM запустил облачную CRM-платформу на базе сервиса SberCloud Managed Kubernetes
ruGPT-3 & family в ML Space: трансформеры для генерации контента
На вебинаре вы узнаете об особенностях обучения и инференса самых «понимающих» трансформенных моделей: ruGPT-3, ruBERT, ruT5, ruRoBERTa, ruCLIP, ruDALL-E. Спикеры продемонстрируют, как в два клика использовать обученные модели в DataHub ML Space и поделятся примерами рыночных кейсов. Вебинар будет полезен дата-сайентистам, менеджерам AI/ML-продуктов, разработчикам, DevOps-инженерам, архитекторам.
Компания SberCloud прошла сертификацию по стандарту PCI DSS
Компания SberCloud подтвердила соответствие IaaS-сервисов требованиям стандарта безопасности платежей PCI DSS
SberCloud выходит на лидерские позиции секторов IaaS и PaaS по итогам 2021
SberCloud стал победителем рейтинга наиболее динамично развивающихся провайдеров секторов IaaS и PaaS по итогам 2021 года. Такой вывод следует из обзора «Российский рынок инфраструктурных облачных сервисов 2021″» международного агентства iKS-Consulting.
Как развернуть стенд для разработки с помощью сервисов облачной платформы SberCloud.Advanced
Хабр, привет! Меня зовут Георгий Липатов. Я — DevOps-инженер, работаю в Сбере, также сопровождаю мониторинг и бэкапы в Sber Tax Free.
Мы начали строить этот сервис в конце прошлого года — тогда наша ИТ-команда состояла из двух backend-разработчиков, DevOps-инженера и пары специалистов по frontend’у. Чтобы не терять время и проверить первые гипотезы, мы решили развернуть стенды для разработки и тестирования в облаке. Помимо решений в области информационной безопасности нам, конечно же, были необходимы удобные инструменты для развертывания, мониторинга и бэкапов. Плюс — масштабируемые ресурсы в зависимости от потребностей проекта.
Как только мы подготовили чуть более развернутое описание наших запросов и рассказали о проекте коллегам из SberCloud, они предоставили нам тестовый доступ и документацию для SberCloud.Advanced. В итоге мы развернули стенды за несколько минут, а еще — сняли с себя необходимость отслеживания обновлений, патчинга и оплаты отдельных инструментов. Последний момент заключается в том, что вместо запуска дополнительной «виртуалки» можно воспользоваться бесплатным сервисом, который предоставляет платформа.
Далее я расскажу о настройке стенда для тестового приложения в формате пошагового туториала. Всех заинтересовавшихся приглашаю под кат.
Запускаем виртуальную сеть
Для начала стоит изолировать среду для разработки от других окружений — например, контуров для тестирования и продакшена. Также стоит сформировать подсети, для которых будут действовать сетевые правила.
Для того чтобы перейти к базовым настройкам, можно воспользоваться веб-интерфейсом для управления сервисами SberCloud.Advanced: перейти в раздел Virtual Private Cloud и нажать Create VPC. В меню настроек — задать название сети (dev-vpc), адрес и маску подсети, а также отметить, что создаваемая виртуальная сеть будет относиться к нашему проекту (выбрать его в выпадающем списке в подпункте настроек Enterprise Project).
Для тестового проекта мы выбрали три подсети — private, public и tools — для backend’а, frontend’а и вспомогательных сервисов соответственно. Для них нужно указать IP-адреса и применить настройки кнопкой Create New.
В результате — мы получили виртуальный ЦОД (dev-vpc) и подсети:
Создаем IP-адреса
После запуска виртуальной сети стоит выделить IP-адреса для пробных проектов. Чтобы это сделать, можно открыть панель управления SberCloud.Advanced, перейти в раздел Elastic IP и кликнуть по кнопке Assign EIP.
В открывшемся меню следует указать число IP-адресов в подпункте Quantity. В нашем случае их будет четыре. Также стоит отметить их принадлежность к нашему проекту (уже знакомый выпадающий список Enterprise Project).
При желании в этом же окне можно задать пропускную способность каналов, но мы оставим этот пункт без изменений и сохраним настройки кнопкой Create.
Далее остается обновить страницу раздела EIPs — там отобразятся только что созданные адреса.
Настраиваем группы безопасности
Перейдем к настройке фаервола, отвечающего за доступ приложений по определённым портам. В рамках туториала будем работать с портами 443 и 80 для веб-сервера, 22 портом для SSH-соединения, и 5432 для базы данных PostgreSQL. Для исходящего трафика оставим опции по умолчанию.
Перед настройкой группы безопасности её необходимо сформировать. Сделать это можно в разделе Virtual Private Cloud. Выбираем пункт Security Groups, нажимаем Create Security Group и во всплывающем окне даем группе имя (в нашем случае — dev-backend-sg), указываем проект, к которому она относится (подраздел Enterprise Project), и подтверждаем действия кнопкой ОК.
Чтобы добавить сетевые правила в только что созданную группу безопасности, нужно кликнуть на название группы (она, конечно же, находится в разделе Security Groups) и перейти во вкладку Inbound Rules в верхней части страницы. В этой вкладке вы увидите правила по умолчанию для портов 443, 80 и 22.
Порт 5432 для PostgreSQL придется открыть вручную. Для этого нажимаем Add Rule, прописываем значение порта во второе поле и в подразделе Source выбираем группу безопасности, где будет работать новое правило.
Вы могли заметить, что в автоматически сгенерированном списке правил присутствует еще открытый порт (TCP: 3389). Мы не планируем использовать его, поэтому удалим в целях безопасности. Для этого достаточно нажать на Delete напротив соответствующего правила и подтвердить операцию.
Исходящие правила пока оставим в виде, заданном по умолчанию.
Развертываем облачный сервер
На этом шаге необходимо указать спецификацию сервера, а также желаемый образ операционной системы, объем жесткого диска и другие настройки. Для примера развернем сервер для нашего backend-приложения. Серверы для frontend’а и других инструментов можно «поднять» аналогичным образом.
В первую очередь нужно перейти в раздел Elastic Cloud Server из панели управления и нажать кнопку Create ECS. Откроется окно, где мы определим регион (в нашем случае — ru-moscow) и зону доступности (AZ1).
Параметры сервера выбираем в подразделе Specifications. Для этого кейса возьмем вариант средней мощности — s6.xlarge.2 с четырьмя ядрами, восемью гигабайтами RAM и гарантированной пропускной способностью в 0,35 Гбит/с.
На этой же странице укажем, под управлением какой операционной системы будет работать сервер (CentOS 8.1), и обозначим объем диска (100 Гбайт).
Далее с помощью кнопки Next перейдем к настройке сети. В новом окне укажем сеть (dev-vpc) и подсеть, в которой будет работать сервер (dev-private-subnet).
Плюс — выберем группу безопасности, определённую ранее. Здесь же в таблице можно будет увидеть все настроенные входящие правила файрвола.
На этой странице остается назначить серверу заранее подготовленный IP-адрес. Для этого нужно поставить галочку Specify EIP. Теперь можно нажимать на кнопку Next и переходить к последнему шагу развертывания сервера.
Осталось задать название (в нашем случае это — dev-backend) и указать ключ-пару для подключения по SSH. Плюс — поставить соответствующую галочку прямо под этим пунктом. Ключ dev-key мы подготовили заранее.
После привязки к нашему проекту (подраздел Enterprise Project) и применения всех настроек на экране появится выделенный сервер с IP-адресом:
Ставим приложения
Подключаемся к серверу через терминал — вводим консольную команду с указанием адреса, выделенного ранее, двадцать второго порта и ключа:
После подключения можно ставить приложения. Для этой задачи мы использовали консольный менеджер пакетов yum:
Настраиваем внутренний домен
Чтобы разработчики могли подключаться через VPN, необходимо создать приватную зону и A-запись. Выбираем в основной панели управления облаком сервис Domain Name Service. Далее в правом верхнем углу нажимаем на Create Private Zone и во всплывающем окне заполняем название домена (для примера — testproject.dev), указываем, что он относится к нашей виртуальной сети (dev-vpc) и прописываем email (опционально). После нажатия на ОК будет сформирована доменная зона, готовая к добавлению записей поддоменов.
В качестве примера сформируем запись поддомена для backend-приложения (кнопка Add Record Set). В этом случае понадобится указать имя (api) и IP-адрес сервера в полe Value (10.0.2.27). Значение TTL уставим по умолчанию.
По аналогии настроим front приложения. Укажем для него адрес 10.0.2.28.
Устанавливаем VPN-сервер
Выбор VPN-сервера полностью зависит от ваших предпочтений. Мы используем Ocserv, так как он бесплатный, легко настраивается и работает с несколькими уровнями безопасности. Найти его можно на Gitlab вместе с документацией.
Используем подход IaC (опционально)
Чтобы упростить процесс, можно обратиться к подходу Infrastructure-as-Code (IaC). Он позволяет управлять развертыванием инфраструктуры с помощью конфигурационных файлов. Далее — приведу небольшой пример, используя Terraform:
Такие файлы можно хранить в системах контроля версий и использовать для автоматизации работы с инфраструктурой. У нас на сервере уже установлен Terraform, и мы заранее подготовили файл с конфигурацией — main.tf.
С его помощью мы «подняли» новую виртуальную сеть — test-vpc. Если мы обновим страницу Virtual Private Cloud в панели управления SberCloud.Advanced, то увидим, что в списке появился новый компонент инфраструктуры.
Если модифицировать конфигурационный файл и заменить в объекте «test-vpc» свойство count 1 на 0, то запуск команды terraform apply приведет к удалению созданной сети:
Добавляем базу данных
Облако SberCloud.Advanced работает с несколькими движками баз данных — MSSQL, PostgreSQL и MySQL и другими. Развертывание, конечно же, происходит в автоматическом режиме. Чтобы осуществить его, нужно перейти в раздел Relational Database Service в панели управления облаком и далее нажать кнопку Create DB Instance. После этого можно будет задать название инстанса (dev-rds), выбрать движок и его версию (PostgreSQL 12). Здесь же важно указать тип инстанса базы данных (Single), зону доступности (AZ1) и временную зону.
На этой же странице мы настроим конфигурацию инстанса для БД и размер диска. Для нашей задачи было достаточно пары ядер, восьми гигабайт оперативной памяти и хранилища на сто гигабайт.
Осталось добавить БД в виртуальную сеть (dev-vpc) и подсеть (dev-private-subnet). Плюс — включить её в группу безопасности (dev-backend-sg), чтобы применить настройки файрвола, и добавить к нашему проекту (подпункт Enterprise Project). Далее — ставим пароль, и БД готова к приему данных.
Для администрирования базы данных в облаке уже развернут инструмент Data Admin Service (DAS). Он доступен в основной панели управления. С его помощью можно формировать схемы, таблицы, запускать SQL-скрипты. Переходим в DAS, вводим только что придуманный пароль и подключаемся к базе данных.
Теперь можно добавлять в БД записи — для примера сформируем БД с названием test. Другие настройки для нее оставим по умолчанию.
Далее войдем в базу — пока что она пустая. Чтобы это исправить, перейдем на вкладку SQL Window в верхней части экрана.
Там мы можем прописать тестовый SQL-скрипт, который создаст таблицу и импортирует в нее информацию:
Просмотреть содержимое можно, вернувшись на вкладку Database management-test (где test — это название нашей БД). Для этого достаточно нажать на Open.
Подключаем мониторинг
Возможным подходом является развертка отдельного сервера с Zabbix или Prometheus и установкой агентов. Облако SberCloud.Advanced предлагает готовый к работе сервис для мониторинга — Cloud Eye.
Внутри Cloud Eye — в подразделе меню Server Monitoring — уже отображается поднятый ранее сервер (dev-backend). Нам остается установить на него агент — для этого нужно кликнуть на Configuration и выбрать пункт Install Agent.
Система сгенерирует команду, которую нужно ввести в терминал:
Она установит агент Telescope, отвечающий за отправку уведомлений и метрик.
После успешного завершения всех операций нам остается лишь обновить конфигурацию. Сделать это можно, нажав на кнопку One-Click Restore во всплывающем окне, из которого мы инициировали установку агента.
Система выполнит необходимые процедуры и сообщит о готовности задачи.
После этого в главном меню Cloud Eye мы сможем увидеть, что в столбце Agent Status появилась запись Running.
Данные мониторинга отражены на специальных dashboard’ах во вкладке OS Monitoring — чтобы её найти, нужно выбрать пункт New Metric (под курсором на скриншоте выше). Инструмент предлагает стандартный набор метрик — производительность CPU, объем используемой памяти, нагрузка на диск и другие. Конечно же, можно сконфигурировать и кастомные графики.
Можно подключить уведомления, которые будут приходить на электронную почту, если показания той или иной метрики войдут в критическую зону. Для задания правил необходимо вернуться в раздел Cloud Eye и перейти в меню Alarm Management — в правом углу будет кнопка Create Alarm Rule.
В настройках указываем название метрики. Мы будем мониторить работу диска, поэтому вписываем dev-low-disk. Здесь же выбираем сервер — dev-backend.
Далее — выбираем шаблон с параметрами уведомления. Платформа предлагает несколько вариантов, однако можно сформировать и свои (Create Manually).
Необходимо указать метрику, которую вы планируете отслеживать, — например, максимальную загруженность диска, другие моменты и не забыть условие срабатывания оповещения. Уведомлению можно придать один из четырех уровней значимости: от информационного до критического.
Собираем логи
Для этой задачи в портфолио платформы SberCloud.Advanced есть инструмент Log Tank. С его помощью на сервер можно добавить агента-сборщика логов.
Чтобы он начал работать, необходимо сгенерировать ключи доступа нажатием на Create Access Key. Верификация происходит путем отправки проверочного кода на электронную почту, привязанную к личному кабинету в облаке.
После нажатия на кнопку ОК и непродолжительной загрузки, будет сформирован ключ доступа. На экране высветится соответствующее сообщение.
Перед установкой агента также нужно создать группу логов для backend-приложения. Для этого возвращаемся в основное меню Log Tank и нажимаем на специальную кнопку — Create Log Group. Во всплывающем окне достаточно прописать имя группы. В нашем случае — это dev-back-log.
Группа отобразится в списке на экране. Выбираем её и кликаем на Create Log Stream в правом верхнем углу, чтобы сформировать поток — dev-back-api.
После нажатия кнопки ОК система предложит установить агент. Прописываем сгенерированные ключи доступа, скопировав их из соответствующего файла.
После этого система сформирует команду для установки из терминала — вот пример такой команды:
После выполнения операции остаётся сообщить системе логирования директорию для трансфера логов. Для этого возвращаемся на вкладку Log Management и по порядку кликаем на записи dev-back-log и dev-back-api.
В меню слева выбираем пункт Host и нажимаем Add Path.
В открывшемся окне необходимо определить сервер (dev-backend), для которого будет вестись запись логов.
После этого можно указать директорию для их хранения. Мы будем писать логи безопасности и сообщений на сервере в /var/log/messages.
После этого в фиде Log Tank (в меню Log Stream) сразу появятся сообщения.
Если выбрать на одну из записей, можно изучить подробную информацию о ней:
Настраиваем резервное копирование
Для этих целей в SberCloud.Advanced тоже есть свой сервис — Cloud Backup and Recovery. Открываем его из панели управления облаком и формируем хранилище для резервных копий нажатием кнопки Create Server Backup Vault.
Выбираем имя сервера из списка (dev-backend).
Чуть ниже указываем объем диска, выбираем из выпадающего списка в пункте Enterprise Project наш проект и даем хранилищу имя — dev-api-backup.
После сохранения настроек в списке хранилищ Cloud Backup and Recovery появляется новая запись. Теперь, если нажать на Bind Backup Policy (из выпадающего меню по клику на More), можно «привязать» к хранилищу бэкапов соответствующую политику.
В настройках политики достаточно указать, когда будет происходить резервное копирование — в какое время, в какие дни. По нашему опыту проводить бэкапы сред разработки стоит по вечерам или в выходные, чтобы не увеличивать нагрузку на сервер в рабочее время.
Резервное копирование можно запустить и принудительно. Достаточно нажать Perform Backup в выпадающем меню More.
После подтверждения операции будет запущено создание резервной копии.
Эту операцию (и другие, находящиеся в очереди) можно найти во вкладке Backups — она отражает статус выполнения задач резервного копирования.
Резервное копирование важно настроить не только для сервера, но и для базы данных. Происходит это похожим образом — сперва находим в панели управления облаком раздел Relational Database Service.
Откроется страница с настроенными базами данных — выберем там dev-rds.
Далее, перейдем к вкладке Backups & restorations, чтобы модифицировать политику — установить время операции и глубину хранения копий.
При создании базы к ней автоматически применяются политики по умолчанию, однако вы можете их поправить в соответствии со своими задачами.
Бэкап базы данных также можно создать вручную. Для этих целей в меню More есть пункт Create Backup.
Появится окно, в котором нужно дать резервной копии понятное название, чтобы было легко определить, для каких целей она создана. Но для примера мы назовем ее просто dev-rds-backup.
После нажатия на ОК, в меню Backup Management возникнет новая задача со статусом Creating. Она как раз формирует наш бэкап.
Включаем балансировщик нагрузки
Его задача — распределять входящий трафик между несколькими экземплярами виртуальных машин. Если трафик сильно возрастает, балансировщик «поднимает» дополнительные инстансы. До начала работы с ним необходимо добавить сертификат. Для этого в главном меню управления облаком выбираем Elastic Load Balance и переходим в подменю Certificates.
Там кликаем на Create Certificate. Во всплывающем окне из выпадающего списка Enterprise Project выбираем проект, также прописываем имя сертификата (в нашем случае — testcert). Мы используем «самописный» сертификат, сгенерированный на сервере — его содержимое и ключ скопированы в соответствующие поля формы. Осталось указать доменное имя (api.sbertaxfree.dev) и можно переходить к настройке балансировщика.
Когда сертификат создан, нажимаем на Create Elastic Load Balancer. В разделах VPC и Subnet с помощью выпадающих меню выбираем виртуальную сеть и подсети, которые мы настраивали в начале туториала. Также прописываем имя балансировщика и указываем его принадлежность к нашему проекту.
После подтверждения настроек в списке Load Balancers появится «свежесформированный» балансировщик.
Система почти готова к работе, осталось настроить «слушателей». Для этого необходимо кликнуть на только что созданный балансировщик и перейти на вкладку Listeners. Тут необходимо прописать порты, с которыми слушатели будут работать. В нашем случае cистема будет принимать трафик по 443 порту. Также в поле SNI Certificate выбираем только что сгенерированный сертификат, он будет перенаправлять потоки данных к серверу на порт 8080.
В следующем окне задаем имя группы для «слушателей» (server-group-api).
Система оповестит об успешном завершении операции.
«Слушателю» нужно «рассказать», с каким трафиком предстоит работать. Для этого идем в Backend Server Groups в настройках «слушателя» и кликаем на Add.
В первом всплывающем окне выбираем сервер dev-backend и нажимаем Next.
Далее определяем порт 8080 — его использует наше приложение.
В результате сервер dev-backend появится в соответствующий вкладке.
Теперь, если мы будем подключаться к нашей сети через VPN, то легко получим доступ к приложениям внутри сети, а балансировщик будет распределять трафик.
Что в итоге
Я рассказал о том, как настроить стенд для разработчиков с помощью PaaS-сервисов. Они работают «из коробки» и позволяют масштабировать ресурсы в зависимости от поставленной задачи. Разумеется, аналогичным образом в облаке можно развернуть и промышленные стенды, хотя для этого потребуется более «глубокая» настройка политик ограничения доступа и механизмов защиты вроде противодействия DDoS и валидации запросов для предотвращения атак с перебором паролей.