Написать пост

Как прокачать разработку с помощью облачных технологий

Логотип компании МТС

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

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

Виртуальная инфраструктура для экономии ресурсов

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

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

Чем хороша виртуальная инфраструктура

  • Не нужно самому покупать и настраивать оборудование (что особенно полезно, если вы небольшая компания с бюджетом на собственный сервер).
  • Можно без проблем увеличивать и уменьшать количество ресурсов самому — через личный кабинет.
  • Не обязательно самостоятельно поддерживать инфраструктуру. Некоторые провайдеры выделяют специалистов, которые работают с виртуальными машинами по заявкам клиента.
  • Не нужно заботиться о надёжности, доступности и отказоустойчивости сервиса — провайдер занимается этим сам.
  • Провайдер гарантирует безопасность. Например, наша платформа защищена центром безопасности (SOC) МТС, предоставляет клиентам антивирус для виртуальных машин и сервис защиты от DDOS-атак.
  • IaaS может автоматизировать масштабирование сервисов по API, например, с помощью Terraform.

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

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

Мы перенесли в облако инфраструктуру бухгалтерского отдела и сопутствующие системы: серверы 1С с базами данных, сервер терминалов, файловый сервер, сервер «Консультант», Active Directory, серверы VPN и DHCP. Безопасность удалённого доступа обеспечили собственным каналом связи и VPN-подключением. А клиент/сервер IPSEC VPN, который входит в состав сервиса Virtual Infrastructure, объединил корпоративную сеть и виртуальную инфраструктуру.

Переход в облако повысил доступность и на 25% ускорил работу ИТ-систем. Теперь при запуске новых продуктов клиент может расширять мощности за 24 часа. В традиционном ЦОДе на это потребовалось бы 1–3 недели.

***

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

DBaaS для простой и быстрой работы с базами данных

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

Развернуть кластер БД стандартной конфигурации можно довольно быстро. Но на то, чтобы настроить мониторинг, регулярное резервное копирование и отказоустойчивость, у отдельного инженера или разработчика может уйти от нескольких дней до нескольких недель — в зависимости от уровня компетенций. И всё равно останется необходимость поддерживать систему и вручную устанавливать обновления. По сути, нужно писать автоматизацию с нуля либо адаптировать существующие open-source или коммерческие решения — и тратить гораздо больше ресурсов.

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

Что она позволяет делать

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

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

Кому не подходит такое решение

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

Если приходит клиент и говорит: «Мне нужен кластер баз данных — но обязательно установите ПО из этого списка, и шифрование только на конкретных дисках», DBaaS не для него. Тут понадобятся professional services, которые работают с нетиповыми конфигурациями.

Другой вариант — ограничение на хранение данных в публичном облаке. Например, работа с персональными данными требует их размещения в облаке, сертифицированном по 152-ФЗ.

Сервис управления кластерами для удобной работы с Kubernetes

Чтобы использовать микросервисную архитектуру, применяются контейнеры, в которые «упакованы» приложения и все их зависимости. Благодаря этому мы можем запускать приложения на одной виртуальной машине, экономить место и не разбираться с «конфликтами» между разными сервисами.

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

На помощь приходят оркестраторы контейнеров, самый популярный из которых — Kubernetes. Но чтобы его развернуть, нужны определённые навыки: поднять виртуальные машины, соединить их по сети, накатить Kubernetes и так далее. Если есть готовые шаблоны, это может занять несколько часов. Но без них — особенно если ты не профессионал — работа растягивается на неопределённое количество времени. И тут появляется сервис управления кластерами.

С помощью сервиса клиента может получить готовый кластер Kubernetes, — выбрать параметры кластера и количество виртуальных машин, и нажать кнопку «Создать». Клиент сразу получает готовый к работе кластер.

Поддержку работоспособности сервиса и все рутинные действия провайдер берёт на себя

  • Обеспечивает бесперебойную работу Control Plane. Если что-то пойдёт не так с мастер-нодами, кластер потеряет управляемость. Мы как провайдер делаем всё, чтобы этого не случилось: настраиваем компоненты, которые разворачиваются на мастер-нодах, подбираем оптимальный размер мастеров, а в ближайших планах — автоскейлинг мастер-нод. И даём пользователю SLA на то, что всё точно будет работать.
  • Предлагает интеграцию с хранилищем «из коробки». Она нужна, чтобы создавать выделенные тома и хранить данные, которые важно не потерять, когда приложение «умирает», а виртуальная машина удаляется.
  • Создаёт балансировщики нагрузки. Просто опишите параметры балансировщика и примените манифест, а провайдер создаст балансировщик и добавит его в кластер.
  • Помогает настраивать плагины. Экосистема Кубера предлагает большое количество программ и расширений, делающих работу в K8s удобнее и эффективнее, но их ещё нужно установить. Мы автоматизируем этот процесс для пользователя.

Настройка плагинов на примере

Возьмём Nginx Ingress Controller. Это балансировщик L7-уровня, который в 99% случаев нужен, чтобы на приложение, которое развёрнуто в Kubernetes, пускать пользовательский трафик.

Пользователь при создании кластера отмечает, что ему нужен этот плагин. А мы под капотом поднимаем сетевой балансировщик, вешаем на него белый IP-адрес, поднимаем L7, устанавливаем Nginx, связываем всё это друг с другом. И гарантируем, что плагин будет работать корректно.

Compute Cloud для удобной работы с виртуалками

Compute Cloud — базовый инструмент любого облачного провайдера. Это простые и понятные виртуальные машины, которыми удобно управлять и которые легко масштабировать. Можно выбрать подходящую ОС или готовый шаблон приложения, чтобы сэкономить время на установку и конфигурацию. Чем он хорош:

  • Низкий порог вхождения. Запустить сервис и создать виртуальную машину может любой человек, мало-мальски разбирающийся в теме. К тому же мы готовим подробную документацию и стараемся делать максимально простые и понятные интерфейсы.
  • Масштабирование. Мы даём возможность менять размер диска и количество CPU и RAM на виртуальной машине. При работе с простым хостингом для масштабирования нагрузки пришлось бы брать новую виртуальную машину и переносить всё в неё.
  • Большой выбор дисков и высокая частота процессора.
  • Экосистема. Compute Cloud — часть экосистемы продуктов, интегрированная со всеми сервисами #CloudMTS. То есть сервис можно превратить в виртуальную инфраструктуру, которую можно будет масштабировать и которой можно будет управлять.

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

Клиенту нужны Kubernetes и база данных, причём редкая, которой нет у облачного провайдера as-a-Service. У него есть выбор:

  • Развернуть базу в Kubernetes. Но Persistent Volumes, то есть хранилища данных, не всегда работают идеально. И считается не очень хорошей практикой хранить высоконагруженные базы данных в Кубере.
  • Развернуть базу в Virtual Infrastructure, но это дольше и сложнее, так как решение больше подходит для больших комплексных проектов.
  • Поднять одну простую виртуальную машину. Если клиент разворачивает не большую комплексную инфраструктуру, а одну базу данных, это оптимальный вариант. И для таких кейсов прекрасно подходит Compute Cloud.

Другой кейс — поднять ВМ и на ней развернуть VPN-сервис. Зачастую это выгоднее, чем покупать подписку на какой-то VPN.

Зачем использовать облачные технологии?

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

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

И мы в #CloudMTS много работаем над тем, чтобы сервисы были простыми, удобными и понятными — без чтения тонны документации. И развиваем хаб, на котором можно самостоятельно управлять разными продуктами: Managed Kubernetes, базы данных, виртуалки и так далее. Регистрируйтесь — там много интересного.

Следите за новыми постами
Следите за новыми постами по любимым темам
975 открытий1К показов