В 2019 году я поставил себе цель погрузиться в изучение JavaScript. На протяжении большей части своей карьеры в сфере технологий я работал в сфере инфраструктуры, поэтому мои программистские навыки были связаны с сценариями bash и всем остальным, что у нас было в то время для автоматизации наших повседневных задач. Совсем недавно я использовал CloudFormation для развертывания и управления моей инфраструктурой в AWS и Ansible для управления конфигурацией. Хотя YAML (или JSON) являются мощным средством определения инфраструктуры и манифестов для поддержки конфигурации инфраструктуры, я также не обязательно рассматриваю эти полноценные языки программирования, это просто не так. В августе 2018 года AWS анонсировала свой Cloud Development Kit (CDK), свою новейшую инфраструктуру в качестве инструмента кода для создания и управления облачной инфраструктурой с использованием различных языков программирования (Python, TypeScript и JavaScript на момент написания этой статьи являются GA). Для меня, как человека, сделавшего карьеру в сфере инфраструктуры, это был идеальный инструмент, чтобы действительно начать изучать язык программирования (я выбрал JavaScript).
Итак, какое отношение все это имеет к моей статье, вы можете спросить? Если честно, ничего. Потому что, когда я начал работать с CDK, я также начал расширяться, фактически выполняя некоторую фактическую работу по разработке на стороне. Между A Cloud Guru и freeCodeCamp я прошел несколько базовых курсов JavaScript, чтобы лучше понять, с чем я работаю. Затем я решил, что возьму на себя ответственность за создание и поддержку веб-сайтов для двух масонских организаций, частью которых я являюсь как вызов самому себе, но имея только самые базовые навыки, мне нужна была структура, чтобы начать работу и учиться. К счастью, в сообществе JavaScript есть Гэтсби, и на этом я остановился.
Для моего сайта (который скоро станет множественным числом) мой хостинг настроен следующим образом; S3, CloudFront и Route 53 - все продукты AWS, которые позволяют мне размещать статический веб-сайт по очень доступной цене. Сайт, которым я сейчас управляю, достаточно прост, так что запускать вручную из командной строки на моей машине разработки не проблема. Однако, как человеку, который проводит свое время на работе, автоматизируя инфраструктуру и развертывание программного обеспечения, где было бы весело делать что-то по старинке? Для этого упражнения помимо трех упомянутых выше сервисов AWS мы добавим GitHub и AWS CodeBuild, чтобы автоматизировать развертывание для нас.
Gatsby - это фреймворк на основе React, который позволяет разработчикам создавать невероятно быстрые веб-сайты и приложения. Сила Гэтсби заключается в его способности извлекать данные из нескольких источников; Системы управления контентом, такие как Contentful, Drupal, WordPress и т. Д., Markdown, или другие источники данных, такие как API, базы данных и т. Д. Его гибкость становится более очевидной по мере того, как вы переходите к хостингу, поскольку довольно просто разместить сайт Gatsby у любого из популярных хостинг-провайдеров, доступных разработчикам. Хотя подавляющее большинство сайтов, созданных с помощью Gatsby, являются статическими, сам фреймворк достаточно гибок, чтобы позволить разработчику также добавлять динамические функции на свой сайт. Добавьте ко всему этому отличную библиотеку стартовых шаблонов, и я надеюсь, вы поймете, почему я решил начать разработку с Гэтсби.
Для целей этой статьи я предполагаю, что у вас уже есть проект Gatsby, и теперь вы находитесь в той точке, где вам нужно развернуть свой код у выбранного хостинг-провайдера. В нашем случае я буду использовать простой одностраничный сайт, размещенный с использованием упомянутых выше продуктов AWS. В дополнение к хостингу мы собираемся использовать GitHub для размещения нашего кода, AWS CodeBuild для сборки и тестирования нашего кода (хотя в моем случае я еще не построил никаких тестов) и плагин Gatsby под названием Gatsby-plugin-s3, который позволит нам развернуть наш код в нашей корзине S3. Для начала мы добавим gatsby-plugin-s3 в нашу базу кода. Убедитесь, что вы находитесь в каталоге своего проекта, затем выполните следующую команду:
$ npm i gatsby-plugin-s3
Затем мы хотим добавить плагин в наш файл gatsby-config.js и настроить его так, чтобы он указывал на нашу корзину S3, в которой будет размещен наш проект;
Затем мы хотим настроить сценарий развертывания в нашем файле package.json. Откройте этот сценарий в выбранном вами редакторе, найдите раздел сценариев и добавьте следующую строку;
Вы заметите, что в официальной документации есть возможность добавить в эту строку –yes, чтобы пропустить запрос на подтверждение. Поскольку мы используем среду непрерывной интеграции (CI) для развертывания нашего кода, нам этот флаг не нужен.
После этого давайте настроим CodeBuild для сборки, тестирования и отправки нашего кода в корзину S3. Первый раздел, который нужно настроить, - это конфигурация нашего проекта. Единственный требуемый раздел - это имя проекта, поэтому убедитесь, что он заполнен именем вашего проекта, и продолжайте, если хотите. Лично мне нравится давать описание, каждый должен включить значки сборки, чтобы украсить свой проект README, и я настоятельно рекомендую добавить теги к вашему проекту в разделе «Дополнительная конфигурация». В зависимости от того, как вы управляете своими учетными записями AWS, теги при правильном использовании могут спасти вам жизнь при определении того, откуда исходят ваши расходы на AWS.
Далее мы настроим раздел Source. Сделайте следующие выборы в этом разделе;
1. Выберите GitHub в качестве поставщика исходного кода.
2. В строке репозитория установите флажок «Репозиторий в моей учетной записи GitHub».
3. Добавьте URL-адрес вашего репозитория в раздел репозитория GitHub (возможно, вам сначала придется войти в GitHub)
4. Выберите запрос на вытягивание, ветвь, идентификатор фиксации и т. Д., Которые вы хотите использовать в качестве исходной версии.
5. Оставьте для глубины клонирования Git значение по умолчанию 1.
В разделе «Первичные исходные события веб-перехватчика» установите флажок «Перестраивать каждый раз, когда изменение кода помещается в этот репозиторий», а затем выберите «PUSH» в качестве типа вашего события.
Затем мы собираемся настроить нашу среду для CodeBuild;
1. Оставьте выбранным по умолчанию «Управляемое изображение».
2. Выберите желаемую операционную систему (я выбрал Ubuntu, потому что моя среда разработки основана на Ubuntu)
3. Оставьте выбранной стандартную среду выполнения по умолчанию.
4. Оставьте для изображения значение по умолчанию «aws / codebuild / standard: 1.0».
5. Оставьте для версии значение по умолчанию «Всегда использовать последний образ для этой версии среды выполнения».
6. Оставьте значение по умолчанию «Linux» выбранным для типа среды.
7. Создайте новую роль службы.
В разделе Buildspec оставьте значение по умолчанию «Использовать файл buildspec». Мы вернемся к приведенному ниже файлу со спецификациями сборки, когда закончим настройку нашего задания CodeBuild.
Для артефактов выберем раздел «Без артефактов». Это связано с тем, что мы используем плагин gatsby-plugin-s3, чтобы поместить наш код в наш исходный Bucket. Если вы когда-либо решили не использовать плагин, вы можете выбрать Amazon S3 и настроить этот раздел в соответствии с требованиями вашего проекта.
Наконец, оставьте кнопку «Журналы CloudWatch - необязательно» отмеченной в разделе «Журналы», и на этом мы закончим настройку нашего проекта. Вы можете нажать кнопку «Создать проект сборки», и мы готовы перейти к следующему шагу.
Итак, теперь у вас есть задание CodeBuild для вашего проекта! Следующее, что нам нужно, чтобы это заработало, - это наш файл buildspec.yml, о котором мы упоминали выше. Ваш файл buildspec.yml - это файл, который сообщает CodeBuild, какие команды и настройки использовать при запуске сборки вашего проекта. Файл называется просто buildspec.yml, и вы сохраняете его в корне проекта исходного каталога. Давайте создадим его прямо сейчас;
Проще говоря, наша работа разбита на несколько этапов; мы устанавливаем Gatsby, устанавливаем наши зависимости, определенные в нашем файле package.json, мы создаем наш проект и, наконец, развертываем его. Если бы у нас были тесты как часть нашего проекта, мы бы просто добавили еще одну фазу, на которой выполняются эти тесты. В разделе артефактов мы определяем, где хранится код нашего проекта и что следует развернуть в нашей корзине S3. В этом случае наш собранный проект хранится в каталоге project, а ** / * сообщает CodeBuild о необходимости рекурсивного развертывания всех файлов в этом каталоге. Параметр discard-paths сокращает путь в артефакте вывода сборки. Если бы, например, у нас был файл с именем /com/mycompany/app/HelloWorld.java, указав yes в нашей спецификации сборки, этот файл просто стал бы HelloWorld.java. Для получения дополнительной информации о файлах Buildspec и обо всех параметрах вы можете прочитать следующую документацию.
Зафиксируйте свой новый файл buildspec и отправьте обновленный репозиторий, и, если все настроено правильно, вы должны увидеть, что ваше задание выполняется из консоли AWS CodeBuild, если вы перейдете к нему. Если нет, дважды проверьте все конфигурации заданий и убедитесь, что они верны.
Поздравляем, вы только что настроили свой проект, чтобы оно автоматически обновлялось при каждом нажатии в репозиторий GitHub! Хотя в этом руководстве вы познакомитесь только с одной моделью хостинга и одной моделью развертывания, вы знаете, что Gatsby можно разместить и развернуть с помощью всех популярных инструментов и сервисов, а не только AWS. Я очень надеюсь, что вы уйдете от этого с твердым пониманием того, как можно настроить решение для автоматического развертывания для вашего сайта Gatsby. Идите вперед и творите великие дела!
