Как подключиться к виртуальной машине yandex cloud ubuntu
Обновлено: 05.07.2024
Добрый день, уважаемый читатель! Сегодня немного расскажу про сервис Яндекс.Облако. Данный сервис предлагаем нам воспользоваться ресурсами компании. Имеется гибкая настройка нужных нам ресурсов, почасовая тарификация и так далее. Так же имеется различная начальная документация для быстрого старта .
Приятным бонусом является то, что все эти сервисы могут работать вместе без дополнительных инструментов. Самым большим спросом требуется работа с базами данных. После этого идет машинное обучение, онлайн переводчик, балансировщик нагрузки.
Сегодня мы более подробно рассмотрим сервис Compute Cloud . Он позволяет быстро получить виртуальный сервер под наши требования. Который будет ограничен только нашей фантазией и заданными ресурсами. Не маловажным будет отметить, что все дата-центры находятся в России и полностью соблюдают все федеральные законы связанные с хранением и обработкой информации.
Приступим к созданию нашего сервера( VDS, VPS - кому как удобнее).
Нажимаем "Создать ВМ" и следуем далее.
ОС можно выбрать из огромного множества уже готовых образов, свежих и стабильных. Как пример Ubuntu 20.04 lts . Одна из самых популярных серверных ОС. Так же на выбор идет накопитель HDD либо SSD . Так же, справа мы видим цену нашей конфигурации, которая меняется в реальном времени от наших потребностей.
Так же мы можем выбрать платформу и поколение которое будет задействовано на нашем сервере. Выбор стоит между Intel Broadwell или I ntel Cascade Lake . Так же для очень емких вычислений имеется Intel Broadwell with Nvidia Tesla v100(Цены в этом сегменте уже приличные). Так же выбираем количество виртуальных ядер( vCPU ). Выбираем Гарантированную долю использования vCPU. Для проектов с высокой нагрузкой рекомендуется использовать 100% использования vCPU. Для проектов средней нагрузки - 50%. Самое интересное, что когда вы поставите 50% - эта планка не может опуститься ниже, но может подниматься выше, вплоть до 100%. Учтите это при создании своего сервера. RAM - количество оперативной памяти, которая будет выделена для вас.
Отдельно выделю пункт : Дополнительно -> Прерываемая . Данный параметр нужен нам при первых тестах нашего сервера, для низкозагруженных и не требующих 100% upTime `а проектов. Данный параметр говорит нам о том, что данный сервер будет прерван через 24 часа. После чего его нужно будет заново запустить. По этому прерываемые сервера предоставляются с огромными скидками . Вплоть до 70%.
Далее у нас идет настройка сети и параметров подсети. И публичных адресов которые так же можно взять в аренду.
Доступ. Доступ к серверу осуществляется по SSH-Ключам . Об этом, более подробно, расскажу в следующей статье. Придумываем логин. Подключаем сервисный аккаунт ели работаете в команде. И видим заветную кнопку " Создать ВМ ". Работать с сервером будет с такими программами как PuTTy и WinSCP . Легкие, базовые программы.
После создания видим такую картину. Наш сервер уже работает. Денюжки уже с наc списываются. Кстати, такая машинка вышла на 501 рубль/месяц .
В следующих статьях я покажу как работать уже непосредственно с самим сервером. Поставим туда, может быть, Python-бота для телеграмма или какой нибудь игровой сервер(CS:GO, Minecraft), для примера. Ведь теперь все эти ресурсы под нашим контролем! До встречи друзья, в следующих статьях! Меня зовут Иван :)
Яндекс.Облако — это набор связанных сервисов, которые помогут вам быстро и безопасно взять в аренду вычислительные мощности в тех объемах, в которых это необходимо. Сервис предоставляет пробный период, в течение которого вы сможете ознакомиться со всеми его возможностями.
В этом блоге мы покажем, как быстро развернуть виртуальную машину с АТС MikoPBX, используя сервис Yandex Compute Cloud.
3) Перед работой с сервисами необходимо создать платежный аккаунт. Внимательно ознакомьтесь с условиями пробного периода. Для создания платежного аккаунта перейдите в раздел Биллинг и добавьте аккаунт
Загрузка образа MikoPBX в облачное хранилище
Перед созданием ВМ необходимо загрузить образ диска с установленной АТС MikoPBX облачное хранилище Object Storage.
1) Скачайте образ MikoPBX из личного кабинета или запросите образ через форму обратной связи. Использовать необходимо образ формата *.raw
2) Перейдите в окно управления облачным хранилищем
3) Создайте новый бакет
4) Установите настройки в соответствии с картинкой
5) Зайдите в созданный в бакет, нажав на него. Нажмите загрузить объекты.
6) Выберите скачанный образ АТС. Нажмите загрузить.
7) После завершения загрузки войдите в загруженный образ, нажав на него.
8) Скопируйте ссылку на образ.
Создание виртуальной машины
1) Перейдите в панель управления облаком. Yandex Cloud → Compute Cloud
2) В разделе Образы нажмите «загрузить образ».
3) Заполните поля «Имя» и «Описание» и в поле «Ссылка» вставьте скопированную ранее ссылку на образ АТС. Нажмите «Загрузить».
4) Дождитесь загрузки образа
5) Перейдите в раздел Виртуальные машины и нажмите «Создать ВМ».
6) Заполните поля «Имя», «Описание». Выберите подходящую для вас зону доступности. О зонах доступности описано в документации сервиса
7) В меню «Выбор образа/загрузочного диска» перейдите на вкладку «Пользовательские», нажмите «Выбрать».
8) В появившемся окне перейдите на вкладку «Образ», выберите загруженный нами образ, нажав на него. Нажмите «Применить».
9) В меню «Диски» появится загрузочный диск.
10) Добавьте еще один диск для хранения записей разговоров. Тип диска «HDD», наполнение «Пустой». Размер диска установите на ваше усмотрение. Наш пример является демонстрационным, мы установили небольшой размер - 2 Гб. Но вы можете установить побольше - 20 Гб
11) Параметры вычислительных ресурсов установите на свое усмотрение исходя из ожидаемой нагрузки на АТС и вашего бюджета.
12) В разделе сетевые настройки создайте облачную сеть. Затем в пункте «Подсеть» нажните кнопку выпадающего списка и добавьте подсеть.
Пункт «CIDR» - диапазон адресов установите из ваших предпочтений. В нашем примере мы установили сеть 172.16.32.0 с маской 24 бита (255.255.255.0). Нажмите «Создать»
Публичный адрес и внутренний адрес оставьте «Автоматически» . Флажок Защита от DDoS-атак мы рекомендуем вам установить.
13) Для доступа к серверу АТС по ssh будет использоваться логин и пароль, по-умолчанию логин root, пароль admin. В генерации ssh ключа нет необходимости, укажем произвольное имя пользователя, а в поле SSH key ssh-rsa
14) На этом настройка ВМ закончена, нажмите «Создать ВМ». Дождитесь ее запуска.
Предварительная настройка АТС MikoPBX
После установки необходимо зайти web-интерфейс АТС, сменить пароль для доступа по ssh, включить FireWall и защиту от взлома.
1) Перейдите в свойства ВМ, нажав на строчку с запущенной ВМ. Скопируйте публичный IP адрес АТС и вставьте в адресную строку браузера.
2) Вы попадете на веб-интерфейс управления АТС MikoPBX. По-умолчанию установлены логин admin, пароль admin.
3) Откроется веб-интерфейс управления АТС.
4) В правом верхнем углу окна веб-интерфеса, смените язык интерфейса на русский.
5) Перейдите в «Сеть и FireWall» → «Сетевой экран». Включите переключатель в положение «Сетевой экран и защита от взлома включены»
6) Измените пароли для web-интерфейса (Система → Общие настройки → Пароль администратора) и ssh (Система → Общие настройки → SSH) на сложные
7) Теперь нужно подключиться к АТС по ssh, подключить дополнительный диск для хранения медиа данных. Подключиться к АТС по ssh вы можете разными способами. Вы можете использовать, например, программу «putty» или расширение «Secure Shell» для браузера Google Chrome. Мы воспользуемся расширением для браузера.
Адрес подключения - Публичный адрес АТС. Логин по умолчанию: «root». порт: «22».
8) При первом подключении к этому адресу утвердительно ответьте в появившемся диалоговом окне. Введите «yes».
9) Введите пароль, который вы установили в (Система → Общие настройки → SSH). Вы попадете в консоль управления АТС.
10) В меню, перемещаясь стрелками, или нажатием на соответствующую цифру, выберите пункт «1 Change Language», переключите язык на русский. Консоль примет следующий вид.
11) Выберите пункт « 6 хранилище данных», затем выберите «1 Подключить диск для хранения данных».
12) Будут показаны доступные для подключения диски. У нас он один. Поэтому просто подтвердите, нажав Enter.
13) После подключения диска вы увидите, что предупреждение «Диск для хранения данных не подключен» перестало отображаться.
После подключения диска, отключаемся от станции и переходим к настройке станции через web интерфейс
Настройка АТС MikoPBX в web интерфейсе
При запуске виртуальной машины по-умолчанию мы получили динамический IP адрес. Для тестирования работы системы он подойдет, но в случае настройки системы в рабочем режиме необходимо получить статический IP адрес. Инструкция по получению статического IP представлена в документации облачного сервиса.
1) Зайдите на web-интерфейс управления АТС.
2) В первую очередь необходимо позаботиться о безопасности системы - настроить сетевой экран и защиту от взлома. Помимо базовой защиты от взлома (fail2ban) вы можете настроить дополнительную защиту от сетевых сканеров.
3) Перейдем в раздел Сетевые интерфейсы. Сервер АТС находится за NAT, поэтому включим соответствующую настройку, укажем публичный IP АТС путем нажатия кнопки «узнать внешний IP» и сохраним настройки.
4) Перейдите на вкладку Сотрудники. АТС поставляется в преднастроенном состоянии, будет доступно для использования три SIP учетные записи. Авторизуем программный софтфон MicroSIP по инструкции под учетной записью 201
5) Подключим провайдер Zadarma к MikoPBX по инструкции и настроим прием всех входящих звонков на номер 201. Совершим наш первый звонок. С любого городского номера позвоним на номер Zadarma, который подключен к MikoPBX. Вызов должен пойти на наш софтфон MicroSIP, авторизованного под 201 учетной записью.
В итоге мы получили собственную облачную АТС MikoPBX развернутую с использованием сервисов Яндекса. Теперь можно приступать к настройке и запуску АТС в рабочем режиме. Дополнительную информацию по настройкам АТС MikoPBX можно найти на wiki.
Настройка локальной сети между компьютером и виртуальной машиной virtualbox является довольно легкой, просто нужно знать некоторые ньюансы, о которых я и расскажу в этой статье.
Далее загружаем виртуальную машину и проверяем сеть.
На ОС Linux из терминала сеть можно проверить так:
В ответ вы должны увидеть работающие сетевые интерфейсы:
По ip можно догадаться, какой интерфейс отвечает за организацию локальной сети между компьютером и виртуальной машиной, по умолчанию (если вы сами не настраивали ip в virtualbox) такой ip должен выглядеть так: 192.168.56.* (вместо * обычно бывает 101 или 102 и т. д.).
Этот ip и нужно использовать для доступа к виртуальной машине.
По умолчанию ip выдается dhcp сервером virtualbox. Для удобства можно задать статический ip адрес в самой виртуальной машине. Например в windows это делается редактированием свойств сети. В интерфейсе linux все аналогично, а вот как это сделать в терминале, без графической оболочки, будет показано ниже, на примере добавления нового сетевого интерфейса в ubuntu server.
В linux бывает, что интерфейс локальной сети между компьютером и виртуальной машиной по умолчанию не задействован, и как следствие, отсутствует локальная сеть. В этом случае необходимо поднять интерфейс локальной сети между компьютером и виртуальной машиной вручную. Далее будет описан процесс задействования сетевого интерфейса в ubuntu server.
Сначала нужно найти название сетевого интерфейса, который нам нужен. В терминале набираем:
В результате вы получите список всех сетевых интерфейсов.
Находим нужный интерфейс, он чаще всего последний. Возможно скорее всего это либо eth1 (для ubuntu server 14.04), либо enp0s8 (для ubuntu server 16.04), все зависит от количества подключенных сетевых адаптеров к виртуальной машине.
Далее редактируем файл /etc/network/interfaces
Файл /etc/network/interfaces для ubuntu server 14.04:
В конец файла добавляем строку (для ip, задаваемого динамически):
Для статического ip:
Вместо eth1 может быть другое название интерфейса, в зависимости от вашей конфигурации.
После этого нужно перезагрузить виртуальную машину и снова набрать команду:
В списке должен появиться интерфейс eth1, или тот, который прописали вы.
Настройка файла /etc/network/interfaces для ubuntu server 16.04:
После внесения изменений так же необходимо перезапустить виртуальную машину, либо можно перезапустить только службу networking:
На ubuntu server 14.04 у меня она не всегда перезапускается, просто продолжает работать, с ubuntu 16.04 в этом плане все впорядке, но для полной уверенности я считаю что лучше все таки перезапустить виртуальную машину.
После перезапуска машины и набора в терминале команды ifconfig в полученном списке сетевых интерфейсов должен появится интерфейс enp0s8.
Что делать, если сетевой интерфейс так и не заработал?
Можете поэксперементировать с типом адаптера для достижения нужного результата.
ssh-доступ к виртуальной машине в virtualbox
После успешной настройки локальной сети между компьютером и виртуальной машиной можно к ней подключиться, например по ssh. Для этого набираем ip адрес, про который я писал вначале статьи, в ssh клиенте и радуемся успешному подключению)
Привет, меня зовут Костя Крамлих, я ведущий разработчик подразделения Virtual Private Cloud в Яндекс.Облаке. Я занимаюсь виртуальной сетью, и, как можно догадаться, в этой статье расскажу об устройстве Virtual Private Cloud (VPC) в целом и виртуальной сети в частности. А ещё вы узнаете, почему мы, разработчики сервиса, ценим обратную связь от наших пользователей. Но обо всём по порядку.
Что такое VPC?
В наше время для разворачивания сервисов есть самые разные возможности. Уверен, кто-то до сих пор держит сервер под столом администратора, хотя, надеюсь, таких историй становится всё меньше.
Сейчас сервисы стараются уходить в публичные облака, и как раз тут они сталкиваются с VPC. VPC – это часть публичного облака, которая провязывает пользовательские, инфраструктурные, платформенные и прочие мощности воедино, где бы они ни находились, в нашем Облаке или за его пределами. При этом VPC позволяет не выставлять без необходимости эти мощности в интернет, они остаются в пределах вашей изолированной сети.
Как виртуальная сеть выглядит снаружи
Под VPC мы понимаем прежде всего оверлейную сеть и сетевые сервисы, такие как VPNaaS, NATaas, LBaas и т. д. И всё это работает поверх отказоустойчивой сетевой инфраструктуры, о которой уже была отличная статья здесь же, на Хабре.
Давайте посмотрим на виртуальную сеть и ее устройство повнимательнее.
Рассмотрим две зоны доступности. Мы предоставляем виртуальную сеть – то, что мы назвали VPC. Фактически она определяет пространство уникальности ваших «серых» адресов. В рамках каждой виртуальной сети вы полностью управляете пространством адресов, которые можете назначать вычислительным ресурсам.
Сеть глобальна. При этом она проецируется на каждую из зон доступности в виде сущности под названием Subnet. Для каждой Subnet вы назначаете некий CIDR размером 18 или меньше. В каждой зоне доступности может быть больше одной такой сущности, при этом между ними всегда есть прозрачный routing. Это значит, что все ваши ресурсы в пределах одной VPC могут «общаться» друг с другом, даже если они находятся в разных зонах доступности. «Общаться» без выхода в интернет, по нашим внутренним каналам, «думая», что находятся в пределах одной частной сети.
На схеме выше показана типичная ситуация: две VPC, которые где-то пересекаются по адресам. Обе могут принадлежать вам. Например, одна для разработки, другая – для тестирования. Могут быть просто разные пользователи – в данном случае это неважно. И в каждую VPC воткнуто по одной виртуальной машине.
Усугубим схему. Можно сделать так, чтобы одна виртуальная машина втыкалась сразу в несколько Subnet. И не просто так, а в разных виртуальных сетях.
При этом, если вам нужно выставить машины в интернет, это можно сделать через API или UI. Для этого необходимо настроить трансляцию NAT вашего «серого», внутреннего адреса, в «белый» – публичный. Выбрать «белый» адрес вы не можете, он назначается случайным образом из нашего пула адресов. Как только вы перестаёте пользоваться внешним IP, он возвращается в пул. Платите вы только за время использования «белого» адреса.
Также есть возможность выдать машине доступ в интернет с помощью NAT-инстанса. На инстанс можно зароутить трафик через статическую таблицу маршрутизации. Мы предусмотрели такой кейс, потому что он бывает нужен пользователям, и мы об этом знаем. Соответственно, в нашем каталоге образов лежит специально сконфигурированный NAT-образ.
Но даже когда есть готовый NAT-образ, настройка может быть сложной. Мы понимали, что для некоторых пользователей это не самый удобный вариант, поэтому в итоге сделали возможность включать NAT для нужной Subnet в один клик. Ещё совсем недавно эта фича была в закрытом preview-доступе, где обкатывалась с помощью участников сообщества. Теперь она доступна всем, кто работает с нашим сервисом.
Как виртуальная сеть устроена изнутри
Как взаимодействует с виртуальной сетью пользователь? Сеть смотрит наружу своим API. Пользователь приходит в API и работает с целевым состоянием. Через API пользователь видит, как всё должно быть устроено и настроено, при этом он видит статус, насколько действительное состояние отличается от желаемого. Это картина пользователя. А что происходит внутри?
Мы записываем желаемое состояние в Yandex Database и идем конфигурировать разные части нашей VPC. Оверлейная сеть в Яндекс.Облаке построена на основе избранных компонентов OpenContrail, который с недавнего времени носит название Tungsten Fabric. Сетевые сервисы реализованы на единой платформе CloudGate. В CloudGate мы тоже использовали некоторое количество open source компонентов: GoBGP – для обращения контрольной информации, а также VPP – для реализации программного роутера, работающего поверх DPDK для data path.
Tungsten Fabric общается с CloudGate через GoBGP. Рассказывает, что происходит в оверлейной сети. CloudGate, в свою очередь, связывает оверлейные сети друг с другом и с интернетом.
Теперь давайте посмотрим, как виртуальная сеть решает задачи масштабирования и доступности. Рассмотрим простой случай. Вот есть одна зона доступности и в ней созданы две VPC. Мы развернули один инстанс Tungsten Fabric, и он тянет в себе несколько десятков тысяч сетей. Сети связываются с CloudGate. CloudGate, как мы уже говорили, обеспечивает их связанность между собой и с интернетом.
Допустим, добавляется вторая зона доступности. Она должна выходить из строя совершенно независимо от первой. Поэтому во второй зоне доступности мы должны поставить отдельный инстанс Tungsten Fabric. Это будет отдельная система, которая занимается оверлеем и мало что знает о первой системе. А видимость, что наша виртуальная сеть глобальна, собственно, и создаёт наш VPC API. Это его задача.
VPC1 проецируется в зону доступности B, если в зоне доступности B есть ресурсы, которые втыкаются в VPC1. Если ресурсов из VPC2 в зоне доступности B нет, VPC2 в этой зоне мы не материализуем. В свою очередь, поскольку ресурсы из VPC3 существуют только в зоне B, VPC3 нет в зоне A. Всё просто и логично.
Давайте пойдём немного глубже и посмотрим, как устроен конкретный хост в Я.Облаке. Главное, что хочется отметить, – все хосты устроены одинаково. Мы делаем так, что только необходимый минимум сервисов крутится на «железе», все остальные работают на виртуальных машинах. Мы строим сервисы более высокого порядка на основе базовых инфраструктурных сервисов, а также используем Облако для решения некоторых инженерных задач, например, в рамках Continuous Integration.
- Compute – часть, отвечающая за распределение вычислительных ресурсов на хосте.
- VRouter – часть Tungsten Fabric, которая организует оверлей, то есть туннелирует пакеты через андерлей (underlay).
- VDisk – это куски виртуализации хранилища.
Инфраструктурные сервисы могут втыкаться в оверлей, но в основном хотят работать именно в андерлее. В андерлей они втыкаются с помощью SR-IOV. Фактически мы режем карту на виртуальные сетевые карточки (виртуальные функции) и просовываем их в инфраструктурные виртуалки, чтобы не терять производительность. Например, тот самый CloudGate запущен в виде одной из таких инфраструктурных виртуальных машин.
Теперь, когда мы описали глобальные задачи виртуальной сети и устройство базовых компонентов облака, давайте посмотрим, как именно разные части виртуальной сети взаимодействуют друг с другом.
- Config Plane – задает целевое состояние системы. Это то, что конфигурирует пользователь через API.
- Control Plane – обеспечивает заданную пользователем семантику, то есть доводит состояние Data Plane до того, что было описано пользователем в Config Plane.
- Data Plane – непосредственно обрабатывает пакеты пользователя.
Как я уже говорил выше, все начинается с того, что пользователь или внутренний платформенный сервис приходит в API и описывает определенное целевое состояние.
Это состояние сразу записывается в Yandex Database, возвращает через API ID асинхронной операции и запускает нашу внутреннюю машинерию, чтобы выдать состояние, которое хотел пользователь. Конфигурационные таски идут в SDN-контроллер и рассказывают Tungsten Fabric, что нужно сделать в оверлее. Например, они резервируют порты, виртуальные сети и тому подобное.
Config Plane в Tungsten Fabric отгружает в Control Plane требуемое состояние. Через него же Config Plane общается с хостами, рассказывая, что именно на них будет крутиться в скором времени.
Теперь посмотрим, как выглядит система на хостах. В виртуальной машине есть некий сетевой адаптер, воткнутый в VRouter. VRouter – это ядерный модуль Tungsten Fabric, который смотрит на пакеты. Если для некоторого пакета уже есть flow, модуль его обрабатывает. Если flow нет, модуль делает так называемый punting, то есть посылает пакет в юзермод-процесс. Процесс разбирает пакет и либо отвечает на него сам, как, например, на DHCP и DNS, либо говорит VRouter, что с ним делать. После этого VRouter может обрабатывать пакет.
Дальше трафик между виртуальными машинами в пределах одной виртуальной сети ходит прозрачно, он не направляется на CloudGate. Хосты, на которых развернуты виртуальные машины, общаются друг с другом напрямую. Туннелируют трафик и прокидывают его друг для друга через андерлей.
Control Plane общаются друг с другом между зонами доступности по BGP, как с другим роутером. Они рассказывают, какие машины где подняты, чтобы виртуальные машины в одной зоне могли напрямую взаимодействовать с другими виртуальными машинами.
А ещё Control Plane общается с CloudGate. Аналогично сообщает, где и какие виртуалки подняты, какие у них адреса. Это позволяет направлять на них внешний трафик и трафик от балансировщиков.
Трафик, который выходит из VPC, приходит на CloudGate, в data path, где быстро пережевывается VPP с нашими плагинами. Дальше трафик выстреливается либо в другие VPC, либо наружу, в пограничные маршрутизаторы, которые настраиваются через Control Plane самого CloudGate.
Планы на ближайшее будущее
- Обеспечивает изоляцию между разными клиентами.
- Объединяет ресурсы, инфраструктуру, платформенные сервисы, другие облака и on-premise в единую сеть.
Постепенно VPC обрастает функциями, мы реализуем новые возможности, стараемся улучшать что-то в плане удобства для пользователей. Некоторые идеи озвучиваются и попадают в лист приоритетов благодаря участниками нашего сообщества.
- VPN как сервис.
- Private DNS инстансы – образы для быстрой настройки виртуальных машин с заранее сконфигурированным DNS-сервером.
- DNS как сервис.
- Внутренний балансировщик нагрузки.
- Добавление «белого» IP-адреса без пересоздания виртуальной машины.
Изначально «белый» IP-адрес можно было добавить только при создании машины. Если пользователь забывал это сделать, виртуальную машину приходилось пересоздавать. То же самое и при необходимости убрать внешний IP. Скоро можно будет включить и выключить публичный IP, не пересоздавая машину.
Не стесняйтесь высказывать свои идеи и поддерживать предложения других пользователей. Вы помогаете нам делать Облако лучше и быстрее получаете важные и полезные функции!
Читайте также: