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

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

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

npm install -g gatsby-cli

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

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

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

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

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

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

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

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

Заходим на 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 МБ через командную строку:

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

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

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

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

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

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

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

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

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

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

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

AWS_ACCESS_KEY_ID = 
AWS_SECRET_ACCESS_KEY =

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

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

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

Устанавливаем плагин:

npm i gatsby-plugin-s3

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

{
  resolve: 'gatsby-plugin-s3',
  options: {
    bucketName: '<bucket-name>',
    region: 'us-east-1',
    customAwsEndpointHostname: 'storage.yandexcloud.net'
  }
}

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

{
  "scripts": {
    "deploy": "gatsby-plugin-s3 deploy --yes"
  }
}

Run&Deploy = Enjoy

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

npm run build && npm run deploy

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

Используемые технологии

Для создания и размещения сайта на своем домене в облаке при помощи платформ Gatsby и Yandex.Cloud мне пригодились технологии:

· VSCode

· Git

· Node.js

· NPM

· React

· Python

· Yandex Identity and Access Management

· СLI Yandex.Cloud

· AWS CLI

· Яндекс.OAuth

· Object Storage

· Yandex Certificate Manager

· Yandex API Gateway

А также были полезны официальные чаты Yandex.Cloud без флуда и мусора — Yandex.Cloud и Yandex Serverless Ecosystem. Это скорая помощь №1 при работе с облачной платформой Яндекса.

Как создать сайт бесплатно самому с нуля на конструкторе яндекс

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

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

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

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

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

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

Сравнение dns-сервисов и выбор

Какими допущениями я руководствовался:

1. В эпоху «суверенного чебурнета» хочется иметь Primary DNS в РФ. Вдруг опятьзабанят Cloudflare?

2. Самостоятельно поднимать, администрировать и защищать DNS-сервер не хочется. Но и от возможностей сервиса ожидается большее, чем указать IP для A-записи.

3. DNS-хостинг может (должен?) быть платный. Если ты не платишь за услугу, то либо она некачественная, либо ты переплатил в другом месте.

4. Основная аудитория сайта находится в РФ. Но идеально – иметь возможность трансфера зоны, используя альтернативный (зарубежный?) Secondary.

5. Возможность выставить минимальный TTL.

6. Хорошо, если публичный «track record» без глобальных падений за последние 5 лет.

7. Если DNS ляжет – импакт должен быть на существенную долю сайтов рунета. Бизнесу не так обидно, когда о падении пишут на всех новостных ресурсах.

Исходя из этих вводных я протестировал шорт-лист из 13 популярных сервисов и собрал в сравнительную таблицу со следующими критериями: наличие бесплатного тарифа, наличие и стоимость платного тарифа, возможность трансфера зоны и использования как Secondary, минимальный TTL, возможность импорта и экспорта зоны, наличие API, наличие защиты от DDoS и использование Anycast, наличие поддержки и дата последнего падения.

Что хотелось отметить отдельно:

Выводы

Все данные и исходники выложены, чтобы каждый мог добавить свои критерии или методологию и выбрать сам. Для себя же я сделал следующий вывод с учётом вводных выше: