Как развернуть стенд для разработки с помощью сервисов облачной платформы SberCloud.Advanced22.09.2021 14:16

Хабр, привет! Меня зовут Георгий Липатов. Я — 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-адресом:

Ставим приложения

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

ssh root@37.18.110.161 -p 22 -i ~/.ssh/dev-key.pem

После подключения можно ставить приложения. Для этой задачи мы использовали консольный менеджер пакетов yum:

yum -y install mc

Настраиваем внутренний домен

Чтобы разработчики могли подключаться через 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:

$ cat main.tf
variable "access_key" {
  default ="ACCESSKEY"
}

variable "secret_key" {
  default ="SECRETKEY"
}

terraform {
  required_providers {
    sbercloud = {
      source  = "sbercloud-terraform/sbercloud"
    }
  }
}

provider "sbercloud" {
  auth_url = "https://iam.ru-moscow-1.hc.sbercloud.ru/v3"
  region   = "ru-moscow-1"
  access_key = var.access_key
  secret_key = var.secret_key
}

resource "sbercloud_vpc" "test_vpc" {
  count = 1
  name = "test-vpc"
  cidr = "10.1.0.0/22"
}

Такие файлы можно хранить в системах контроля версий и использовать для автоматизации работы с инфраструктурой. У нас на сервере уже установлен 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-скрипт, который создаст таблицу и импортирует в нее информацию:

CREATE TABLE links (
	id SERIAL PRIMARY KEY,
	url VARCHAR (255) NOT NULL,
	name VARCHAR (255) NOT NULL,
	description VARCHAR (255),
		last_update DATE
);
INSERT INTO links (url,name)
VALUES (‘https://www.postgresqltutorial.com’,’PostgreSQL Tutorial’);

Просмотреть содержимое можно, вернувшись на вкладку Database management-test (где test — это название нашей БД). Для этого достаточно нажать на Open.

Подключаем мониторинг

Возможным подходом является развертка отдельного сервера с Zabbix или Prometheus и установкой агентов. Облако SberCloud.Advanced предлагает готовый к работе сервис для мониторинга — Cloud Eye.

Внутри Cloud Eye — в подразделе меню Server Monitoring — уже отображается поднятый ранее сервер (dev-backend). Нам остается установить на него агент — для этого нужно кликнуть на Configuration и выбрать пункт Install Agent.

Система сгенерирует команду, которую нужно ввести в терминал:

cd /usr/local && wget https://telescope-ru-moscow-1.obs.ru-moscow-1.hc.sbercloud.ru/scripts/agentinstall.sh && chmod 755 agentinstall.sh && ./agentinstall.sh

Она установит агент 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.

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

После этого система сформирует команду для установки из терминала — вот пример такой команды:

Curl http://icagent-ru-moscow-1.obs.ru-moscow-1.hc.sbercloud.ru/ICAgent_linux/apm_agent_install.sh > apm_agent_install.sh && REGION-ru-moscow-1 bash apm_agent_install.sh -ak NADYN***WOIRG -sk 8VMid6YN***21ZN8oQs -region ru-moscow-1 -projectid 0c424f5e840026e42f05c00e3f11e0cb -accessip 100.125.13.65 -obsdomain obs.ru-moscow-1.hc.sbercloud.ru

После выполнения операции остаётся сообщить системе логирования директорию для трансфера логов. Для этого возвращаемся на вкладку 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 и валидации запросов для предотвращения атак с перебором паролей.

На платформе SberCloud.Advanced есть соответствующие решения и не только они. Вы можете оценить работу всех облачных сервисов SberCloud самостоятельно, зарегистрировавшись в личном кабинете на сайте. Если возникнут вопросы, можно связаться с поддержкой по электронной почте support@sbercloud.ru или написать в Telegram-чат.

© Habrahabr.ru