Storage yandexcloud net что это
Как разместить статический сайт с помощью Yandex.Cloud Object Storage
Привет, Хабр!
В этой статье, я расскажу как легко и просто разместить статический сайт с помощью технологий Яндекса, а именно Object Storage.
В конце у вас будет размещенный в сети сайт, который будет доступен по внешней ссылке.
Эта статья будет полезна, если вы
О себе
Недавно, я разрабатывал SaaS сервис, подобие маркетплейса, где люди находят спортивных тренеров для персональных тренировок. Использовал стек Amazon Web Services (далее AWS). Но чем глубже погружался в проект — тем больше нюансов узнавал о разных процессах организации стартапа.
Я столкнулся с следующими проблемами:
Вдохновленный статьей о мигрировании инфраструктуры из Amazon Web Services в Яндекс.Облако, я решил изучить стек Яндекса подробнее.
Для меня ключевыми особенностями Яндекс.Облака было следующее:
Я изучал других конкурентов этого сервиса, но на тот момент Яндекс выигрывал.
О себе рассказал, можно и перейти к делу.
Шаг 0. Подготовим сайт
Для начала нам понадобится сайт, который мы хотим разместить в интернете. Так как я Angular разработчик, я сделаю простой шаблон SPA приложения, который далее размещу в интернете.
P.S. Кто разбирается в Angular или знает про его документацию https://angular.io/guide/setup-local, переходите к Шагу 1.
Установим Angular-CLI чтобы создавать SPA-сайты на Ангуляре:
Создадим Angular приложение с помощью следующей команды:
Далее переходим в папку приложения и запускаем его, чтобы проверить работоспособность:
Приложение создано, но пока не готово к размещению на хостинге. Соберем приложение в небольшой билд (Production), чтобы убрать все лишнее и оставить только необходимые файлы.
В ангуляре это можно сделать следующей командой:
В результате этой команды в корне приложения появилась папочка dist с нашим сайтом.
Работает. Теперь переходим к хостингу.
Шаг 1.
Переходим на сайт https://console.cloud.yandex.ru/ и жмем на кнопку «Подключиться».
После успешной регистрации и авторизации, мы в личном кабинете.
Далее слева в меню нужно найти сервис «Object Storage», который мы как раз будем использовать для хостинга сайта.
Коротко по терминам:
Создадим один из них. Для этого в консоли сервиса жмем на кнопку «Создать бакет».
В форме создания бакета есть следующие поля, пробежимся по ним:
Жмем «Создать бакет» и бакет создан.
Теперь нужно загрузить наш сайт в бакет. Самый простой способ — открыть рядом папочку dist нашего сайта и ручками перетащить прямо на страницу. Это удобнее, чем жать на кнопку «Загрузить объекты», потому что в таком случае папки не переносятся и их придется создавать ручками в правильной последовательности.
Итак, сайт загружен в хранилище, тем можем предоставить пользователям возможность обращаться к хранилищу, как к сайту.
Для этого слева в меню жмем на вкладку «Веб-сайт».
На странице настройки бакета как сайта, выбираем таб «Хостинг». Здесь указываем главную страницу сайта, обычно это index.html. Если у вас SPA приложение, то вероятно все ошибки обрабатываются также на главной странице, поэтому укажем на странице ошибки также index.html.
Мы сразу видим, по какой ссылке будет доступен наш сайт. Жмем сохранить.
Через минут 5, перейдя по ссылке мы видим что теперь наш сайт доступен всем желающим.
Спасибо всем кто дочитал до конца! Это моя первая статья, планирую дальше описать другие сервисы Яндекса и их интеграцию с frontend и backend технологиями.
Напишите в комментариях насколько интересно вам узнать про другие сервисы Яндекса или про использование Angular в современной разработке.
Как сделать и разместить статический сайт на 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 МБ через командную строку:
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 на свои:
Создание превью картинок в объектном хранилище с помощью Yandex Cloud Functions
Довольно распространенная задача – создание превью картинок для сайта из полноразмерных изображений. Автоматизируем этот процесс с помощью триггера для Yandex Object Storage с функцией в Yandex Cloud Functions, которую он будет запускать с наступлением определенного события в бакете – в нашем случае, появлением в нем картинки. Функция сделает из нее превью и сохранит в соседний бакет. Возможна вариация сохранения превью в тот же бакет, но с другим префиксом.
Также с помощью триггера в Yandex.Cloud можно задавать действия не только для объектов в хранилище, но и для событий в очереди.
Триггер для Object Storage и Cloud Functions
Для решения этой задачи необходим настроенный бакет в Object Storage, в него будут загружаться файлы и в нем же будет лежать архив с кодом функции. Репозиторий с примером кода можно скачать тут. После выполнения инструкций из репозитория у вас будет готовая функция, к которой необходимо подключить триггер, срабатывающий на загрузку новых файлов.
В настройках триггера задаем его параметры: название, описание и тип – в нашем случае Object Storage. Также указываем бакет, в который будут загружаться картинки. Если дополнительно указать префикс и суффикс объекта, то можно обойтись одним бакетом и для исходных файлов, и для превью.
Далее указываем имя нашей функции, интервал повторных запросов и создаем триггер. Готово, теперь после загрузки картинке будет автоматически создаваться ее превью.
Превью на лету
Но у такого решения есть пара ограничений.
Превью создаются только для новых изображений, если картинка уже лежала в бакете, то для нее превью не будет создано.
Необходимо заранее определять высоту и ширину превью, чтобы внести изменения в соотношение сторон или размер необходимо заново масштабировать все картинки.
Теперь схема будет работать так.
При первичном обращении за превью:
Пользователь запрашивает картинку, указав в URL ее желаемые размеры.
Объектное хранилище не находит нужного файла и согласно настроенным правилам, переадресует запрос в функцию.
Функция идет за оригинальным изображением в объектное хранилище.
Масштабирует его до нужных размеров и сохраняет по ключу, содержащему эти размеры.
Сразу отдает готовый файл пользователю.
При последующих обращениях за файлом пользователь будет сразу получать файл из объектного хранилища без вызова функции.
Особенности технической реализации
Прописываем правила переадресации для бакета, чтобы Object Storage и Cloud Functions смогли работать в связке.
Например, при обращении к %bucket_name%.website.yandexcloud.net/images/500×500/cats/meow.png вы получите картинку которую положили в бакет %bucket_name% по ключу images/cats/meow.png но отмасштабированную до размеров 500x500px.
Чтобы не выстрелить себе в ногу
Если не задать значение переменной окружения ALLOWED_DIMENSIONS, то в функции не будут накладываться ограничения на размеры. Это значит, что если будут запрошены много разных вариантов размеров, то все они будут созданы и загружены в объектное хранилище. Поэтому если вы точно знаете, что вам понадобятся определенные размеры картинок лучше их указать. В противном случае, вы быстро израсходуете все свободное пространство хранилища.
Так же, если у вас очень много изображений, можно задать некоторое значение TTL, создать LRU схему кэширования.
Любые вопросы по Serverless и Yandex Cloud Functions обсуждаем у нас в Telegram: Yandex Serverless Ecosystem