Yandex cloud yc linux

Copy raw contents

Начало работы с интерфейсом командной строки

Интерфейс командной строки << yandex-cloud >> (CLI) — скачиваемое программное обеспечение для управления вашими облачными ресурсами через командную строку.

Если вы еще не подключены к консоли управления, войдите в [консоль](<< link-console-main >>) и примите пользовательское соглашение (нажмите Войти).

От имени пользователя

Чтобы аутентифицироваться от имени пользователя:

Получите OAuth-токен в сервисе Яндекс.OAuth. Для этого перейдите по [ссылке](<< link-cloud-oauth >>) и нажмите Разрешить.

Запустите команду yc init , чтобы выполнить настройку вашего профиля CLI.

По запросу команды введите свой OAuth токен.

Выберите одно из предложенных облаков, в которых у вас есть права доступа:

Если вам доступно только одно облако, оно будет выбрано автоматически.

Выберите каталог по умолчанию:

Выберите зону доступности по умолчанию для сервиса << compute-full-name >>:

Проверьте настройки вашего профиля CLI:

От имени сервисного аккаунта

Перед началом работы подготовьте сервисный аккаунт:

От имени федеративного пользователя

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

Источник

Как сделать и разместить статический сайт на Gatsby в Yandex.Cloud

Пошаговая инструкция по деплою статического сайта в облако, прикрутке к нему сертификата Let’s Encrypt, домена второго уровня и настройке API-шлюза

Идея познакомиться с serverless на практике меня привлекала так же сильно как и желание потестировать с пользой один из генераторов статических сайтов.

Я присматривалась к скоростному Gatsby c пушечными стартерами — платформе open source, сделанной на React, и к облачной платформе Yandex.Cloud, где есть опция хостинга статических сайтов. К тому же надо было обновить портфолио.

C нуля и до деплоя я реализовала свои идеи: serverless + быстрый сайт + портфолио. В процессе загрузки своего приложения в облако Яндекса я познакомилась с дружелюбным и быстрорастущим коммьюнити Yandex.Cloud в Telegram и побывала на конференции Gatsby. Это еще пара мощных профитов ко всему полученному опыту.

Хочу поделиться пошаговым процессом деплоя в облако и прикрутки к облаку своего домена разными способами — к бакету и к API Gateway. Пусть мое руководство сэкономит время таким же страстным поклонникам красивых быстрых serverless-технологий и адептам JAM-подхода.

Из текста вы узнаете, как:

выложить статический сайт на Gatsby в Object Storage;

выпустить и привязать сертификат Let’s Encrypt через Yandex Certificate Manager;

подключить Object Storage и привязать домен к API Gateway или бакету.

1. Создаем свой сайт на Gatsby

Идем на сайт Gatsby и находим раздел со стартерами. Залипание на стартерах можно оставить на потом. Первым делом устанавливаем генератор статических сайтов.

Выбираем стартер и клонируем его себе. Под каждым стартером есть команда со ссылкой на репозиторий:

Переходим в папку проекта:

Запускаем локальный сервер для разработки сайта:

По умолчанию Gatsby запускает локальную среду разработки на порту 8000:

Если история с шаблонами неинтересна, можно создать заготовку своего проекта на Gatsby.

На этом все настройки для создания своего статического сайта на Gatsby по готовому шаблону закончены. Можно начинать адаптировать сайт под себя.

2. Регистрируем домен

Вам нужен домен третьего уровня — это основная идея. Так вы избежите танцев с www-бубном, которые я исполняла, когда захотела разместить свой сайт на домене второго уровня — edibleclouds.ru.

Почему третьего? Для домена третьего уровня можно прописать CNAME DNS-запись, указывающую на URL. Кроме того, домен третьего уровня нужен для создания API-шлюза.

Если у вас уже есть готовый домен второго уровня, и вы хотите, чтобы ваш сайт работал из облака именно на нем, а еще через API-шлюз, то придется немного покружиться в шаманском танце из пунктов 11-13 данного руководства.

После того как домен создан, переходим к работе с хранилищем через сервис Object Storage.

3. Создаем бакет в объектном хранилище

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

Мы оказываемся в личном кабинете Yandex.Cloud, где создаем свое Облако, а в нем — сервисный каталог, из которого удобно работать со всеми используемыми сервисами Yandex.Cloud.

В консоли управления слева находим сервис Object Storage. В инструкции Как начать работать с Yandex Object Storage описано, как начать с ним работать. Объектное хранилище Yandex.Cloud совместимо с аналогичной технологией Amazon S3. Им тоже можно управлять через CLI и пользоваться для хостинга статических сайтов.

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

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

Пройдемся по параметрам бакета.

Макс. размер — указываем примерный вес сайта, не больше: так проще будет контролировать расходы и меньше шансов выйти за допустимый предел. Мы платим за объем, который занимают наши данные.

Доступ на чтение объектов — нам нужен вариант «Публичный», чтобы на клиенте корректно рендерилась верстка и отрабатывали скрипты.

Доступ к списку объектов и Доступ на чтение настроек — в «Ограниченном» режиме бакет будет работать как внутреннее хранилище файлов.

Класс хранилища — оставляем «Стандартный». Пользователи будут скачивать файлы при каждом новом посещении. А значит, это тоже влияет на стоимость услуги.

Объяснение к параметрам бакета я взяла на Хабре, в примере размещения в Object Storage сайта на Angular.

Все, бакет с именем домена готов к тому, чтобы задеплоить в него локальный проект. Но наш проект сделан на Gatsby, он не собран, и просто руками перетащить файлы туда не получится. Я поизучала работу Yandex.Cloud и залила в бакет сырой проект со всеми node_modules весом 500 МБ через командную строку:

За это в Yandex.Cloud улетело около 18 из 3000 рублей, предоставленных на пробный период. Ну, хорошо, что не как в эпичном кейсе ребят из калифорнийского стартапа MilkyWay, которые сожгли на тесте Google Cloud и Firebase 72K $ за два часа.

Serverless-провайдеры хороши тем, что берут плату только за те ресурсы, которые ты тратишь — это главный принцип бессерверности. Если нужно больше ресурсов, масштабирование происходит автоматически.

Для сборки и деплоя моего сайта мне пригодился плагин S3, который есть у Gatsby. Чтобы им воспользоваться, мне понадобились: сервисный аккаунт, статический ключ доступа и консольные клиенты — CLI Yandex и AWS CLI.

Чтобы все это получить, я прошла процедуру аутентификации через Yandex Identity and Access Management — сервис идентификации и контроля доступа, который помогает централизованно управлять правами доступа пользователей к вашим ресурсам.

4. Устанавливаем CLI Yandex.Cloud и создаем профиль

Интерфейс командной строки Yandex.Cloud нам понадобится для работы от имени сервисного аккаунта:

Чтобы создать профиль, получаем OAuth-токен в сервисе Яндекс.OAuth. Токен будет сохранен в конфигурации профиля, и аутентификация будет происходить автоматически.

Пошаговый процесс установки CLI и получения OAuth-токена описан в документации Yandex.Cloud, в разделе Начало работы с интерфейсом командной строки.

5. Создаем сервисный аккаунт, назначаем ему роли, проходим аутентификацию от его имени

От имени сервисного аккаунта программы могут управлять ресурсами в Yandex.Cloud.

Подробно о том, зачем нужны сервисные аккаунты, написано в документации Yandex.Cloud, в разделе Сервисные аккаунты.

Как аутентифицироваться от имени сервисного аккаунта написано в разделе Аутентификация от имени сервисного аккаунта.

Как назначить роли сервисному аккаунту и какие они бывают, читайте в разделе Назначение роли сервисному аккаунту.

6. Cоздаем статический ключ доступа для сервисного аккаунта в Yandex.Cloud

Статические ключи доступа — секретный ключ и идентификатор ключа — используются только в сервисных аккаунтах для аутентификации в сервисах с AWS-совместимым API, например в Object Storage.

Как создать статический ключ доступа, читайте в документации Yandex.Cloud, в разделе Создание статических ключей доступа.

Дальше, чтобы каждый раз не указывать переменные окружения при деплое, мы создаем файл с расширением env и прописываем в нем секретный ключ и идентификатор ключа, которые мы получили:

И добавляем файл в проект.

7. Настраиваем консольный клиент к S3

Object Storage поддерживает некоторые методы HTTP API Amazon S3, поэтому тут можно воспользоваться популярными инструментами для работы с этим сервисом. Настроим консольный клиент — AWS CLI. Нам нужна вторая версия.

Читайте раздел AWS Command Line Interface, чтобы понять, как пользоваться AWS CLI для работы с Object Storage.

7. Подключаем плагин S3

Теперь осталось подключить плагин, добавить несколько строк кода и можно деплоить проект в бакет.

Добавляем код в папку plugins файла gatsby-config.js. Подставляем вместо имя бакета. Обратите внимание на регион. Оставляем его именно таким, несмотря на то, что в инструкциях можно встретить указание везде прописывать ru-central1.

В package.json в секцию scripts добавляем «deploy».

9. Run&Deploy = Enjoy

Запускаем. Проект сбилдится и загрузится в указанный бакет.

Не обращайте внимания на вывод в консоли. Там будет указан адрес для AWS S3 независимо от того, какой хост указан в переменной customAwsEndpointHostname.

В разделе Статический веб-сайт в Yandex Object Storage в пунктах 4-10 описано, как настроить главную страницу и страницу ошибки.

Но наш сайт сейчас работает по HTTP. Создадим защищенный протокол.

10. Выпускаем сертификат Let’s Encrypt

Сертификат нам понадобится как для создания безопасного соединения по HTTPS, так и для API Gateway, чтобы использовать домен для обращения к API.

Создаем сертификат через сервис Certificate Manager. Инструкция по созданию лежит в разделе Создание сертификата от Let’s Encrypt документации.

Для тех, у кого домен второго уровня: я создаю сертификат сразу для двух доменов — с www и без.

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

Как мы видим на скриншоте, можно выбрать два способа проверки: через HTTP или через DNS. В инструкции Как начать работать c Certificate Manager, по которой я шла, было сказано выбрать тип проверки HTTP. Но во всех других инструкциях, например в инструкции Проверка прав на домен, было написано, что можно выбрать любой тип.

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

Для HTTP-валидации нужно создать файлы для обоих доменов с названием, указанным в блоке Ссылка для размещения файла, положить туда Содержимое и добиться того, чтобы эти файлы открывались по ссылке. Обратите внимание — файлы должны быть без расширения txt в конце. Это критично для процедуры проверки.

Как только мы убедились, что оба файла доступны по ссылке, можем переключаться на другие дела. Процедура проверки запущена. В лучшем случае через шесть минут статус из Pending сменится на Valid, а Validating — на Issued.

11. Настраиваем доступ по HTTPS

Сертификаты готовы, и теперь мы можем настроить доступ по HTTPS к нашим бакетам и доменам.

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

Если делать валидацию через DNS, то сертификат продлевается автоматически.

Доступ к бакету по HTTPS открывается в течение получаса после выбора сертификата.

12. Подключаем домен к бакету

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

Домен второго уровня подключить к Облаку напрямую нельзя — такие домены не направляются на другой хост при помощи изменения записи CNAME. Поэтому мы создавали два бакета и делали сертификат на каждый. Подробнее об этом читайте в документе Common DNS Operational and Configuration Errors, п.2.4.

Сейчас пришло время добавить ресурсную запись CNAME у субдомена. В моем случае это www.edibleclouds.ru. Для этого в редакторе DNS у своего регистратора прописываем:

И далее направляем домен на бакет:

Способ рабочий, но не самый надежный. IP облака может измениться, сайт упадет, а вы про это даже не узнаете. По словам Джорджа из облачного чата, IP у облака не менялся уже два года, и ничего не предвещает изменений в будущем.

Чтобы мой основной домен edibleclouds.ru смотрел в облако, нужно у регистратора поменять запись типа A, указав IP Облака вместо IP того сервера, на чьи DNS мой домен делегирован.

Затем идем в редактор DNS своего регистратора и меняем в А-записи этот адрес на адрес Yandex.Cloud — 93.158.134.163. Все, через минут 10 домен будет смотреть в облако.

б) Через DNS у регистратора

На примере reg.ru процесс настройки собственного домена третьего уровня через DNS пошагово описан в разделе Статический веб-сайт в Yandex Object Storage документации.

В случае работы с доменом второго уровня делаем переадресацию из бакета с www на бакет с именем домена второго уровня во вкладке Веб-сайт.

13. Cоздаем API-шлюз, подключаем домен к шлюзу

В Yandex.Cloud можно создать API-шлюз и настроить свой домен третьего уровня для обращения к шлюзу. С технической точки зрения для статического сайта выгоднее и удобнее размещать сайт и прикручивать домен к Object Storage. Это дешевле и требует меньше настроек.

Но сервис API Gateway позволяет более гибко настроить сайт и добавить в него динамику, когда это потребуется. Я подключила домен к API Gateway еще на статике, и потому рассказываю тут, как это делается.

Домен можно использовать из сервиса Certificate Manager, при этом для TLS-соединения будет использован привязанный к домену сертификат. В моем случае это домен www.edibleclouds.ru и сертификат Let’s Encrypt.

Чтобы подключить домен к шлюзу сначала мы создаем шлюз, а затем подключаем домен.

Для этого я также размещаю у своего регистратора (в моем случае это nic.ru) CNAME-запись такого вида.

Домен в консоли должен быть в списке и в статусе Valid. Статус означает, что Yandex.Cloud может принимать трафик с вашего домена.

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

Чтобы домен работал как шлюз, нам нужно настроить шлюз на бакет — интегрировать API Gateway c Object Storage. Это делается в спецификации YAML. Найдите в правом верхнем углу меню Редактировать.

Можно скопировать спецификацию отсюда. Только замените url, bucket и service_account_id на свои:

Источник