В это Рождество мне удалось подхватить сильнейшую простуду за последние годы. Вместо того, чтобы бросить вызов Праздничные 500 км, я решил остаться дома и освежить в памяти некоторые технологии, одновременно выполняя некоторую уборку веб-сайта для willmorgan.co.uk.

За 2 года работы с сайтом в Интернете я усвоил несколько передовых методов и научился нескольким приемам. У меня было несколько конкретных целей:

  • Включить HTTPS
    Google начнет наказывать веб-сайты, не поддерживающие HTTPS, в 2017 году.
  • Убедитесь, что веб-сайт можно разработать и развернуть откуда угодно
    Я начал разрабатывать на своем компьютере, но при выполнении некоторых обновлений на новой машине мне было сложно настроить среду разработки.
  • Упростите и автоматизируйте инструменты сборки
    Мой текущий процесс сборки подвержен ошибкам и немного вспыльчив.
  • Сократите финансовые и временные затраты на хостинг
    . Учитывая, что это единственный статический веб-сайт, платить 5 долларов США за 1% за хостинг на DigitalOcean - это слишком большие деньги и требует слишком большого обслуживания. Кроме того, после того, как я возился с ужасными поставщиками виртуального хостинга еще в начале 2000-х и снова в этом году, я больше никогда не буду этого делать.

Обзор стека

Веб-сайт:

  • Состоит из полностью статического HTML, CSS, JS, изображений.
  • Использует Gulp для создания веб-сайта - минификация, объединение, сжатие изображений и т. Д.

Метод конвейерной передачи данных в Gulp элегантен и дает вам много возможностей управления независимо от того, нужен он вам или нет. В наши дни я использую сценарии npm для выполнения большинства задач, что привлекательно, поскольку этот подход не требует дополнительных библиотек, никаких адаптеров для ванильных инструментов командной строки, а также делает некоторые полезные предположения о вашей среде при запуске сценариев таким образом, например как добавление ваших локально установленных двоичных файлов Node в среду сценария, что сокращает необходимость установки библиотек глобально.

Я также использовал Webpack в производстве для других проектов. В отличие от Gulp, он охватывает как сборку, так и загрузку ресурсов. Он также в основном основан на конфигурации и предлагает множество плагинов для настройки его функциональности. Он по-прежнему требует немного адаптера и упаковки, а также немного большей конфигурации, чем может быть комфортно новичку, но он хорошо справляется со своей задачей.

Старая среда:

  • Сидит на коробке DigitalOcean Ubuntu + Apache для хостинга
  • DNS-хостинг предоставляется AWS Route 53.
  • Требуется правило .htaccess и некоторые переменные среды, чтобы гарантировать, что собранный код обслуживается.
  • Использует Vagrant для создания виртуальной машины для разработки

Коробки DigitalOcean слишком много для размещения статического веб-сайта, и, вероятно, пора отказаться от нее. Тенденция DevOps и облачных решений действительно поражает здесь - громоздкие задачи по отслеживанию исправлений для последних CVE, обработке обновлений программного обеспечения и резервному копированию - это бремя.

Поскольку в настоящий момент развернут весь сайт, я полагаюсь на некоторые переменные среды для переключения между исходным каталогом и каталогом распространения при обслуживании сайта. Я хотел бы свести к минимуму количество кода, зависящего от среды - переключение общедоступных каталогов в файле конфигурации Apache не идеально, если оно ненадежно - даже если это из-за моего собственного незнания!

Наконец, создание Vagrant VM объемом 1 ГБ для разработки статического веб-сайта - безумие. Я нашел альтернативу - пакет npm http-server. Он достаточно настраиваемый, чтобы обрабатывать настройку SSL и CORS, и даже поддерживает GZIP на базовом уровне. В то время как Vagrant великолепно предоставляет среду с дополнениями, более портативная библиотека, которую можно установить вместе с devDependencies проекта, безусловно, предпочтительнее.

Развертывания:

  • Теоретически работает автоматически с хуками Git, но мой код на сервере темпераментный ...
  • Требовать фиксации встроенного исходного кода в папку dist /.

В какой-то момент все работало гладко - обработчик пост-приема GitHub запускал сценарий развертывания на моем сервере, который загружал последние изменения, чтобы они отображались на рабочем сервере. Спустя несколько лет и несколько обновлений Apache / Ubuntu ситуация изменилась.

Раскрытие функциональности развертывания в производственной среде, даже если она защищена некоторой аутентификацией, немного небезопасно и нарушает шаблон «статическое все». Здесь предпочтительнее одностороннее развертывание.

Убедившись, что я выполнил команду перед фиксацией и отправкой изменений в репозиторий Git, в данном случае gulp build для минимизации скриптов, меня продолжало ловить. Собранные файлы также не представляют особой ценности - когда дело доходит до отслеживания истории, когда доступны разборчивые исходные файлы, я предпочитаю читать исходные файлы, а не артефакты сборки.

В наши дни я больше полагаюсь на службы CI, чтобы выполнять задачи сборки нейтральным, легко воспроизводимым образом. Функциональность сценариев означает, что вы никогда не забудете снова запустить gulp build, и это также означает, что вы можете выполнить развертывание с любого компьютера, если у вас есть git push доступ.

Новый стек

Наконец-то я перешел на AWS S3 и CloudFront, чтобы обслуживать сайт статически. У меня есть Travis CI, занимающийся сборками и загрузками.

Чтобы настроить эти службы, нужно немного научиться, но если вы никогда не делали этого раньше, вот краткое руководство:

  • S3 (Simple Storage Service) - это служба хранения, которая позволяет загружать данные в Интернет. У вас есть контроль над такими вещами, как права доступа к файлам, и вы получаете набор функций для некоторого преобразования файлов. Вы можете размещать веб-сайты с помощью S3 с небольшим волшебством, хотя вам может потребоваться служба хостинга DNS AWS, Route 53, чтобы немного упростить этот процесс.
  • CloudFront - это сеть CDN, которая реплицирует ваш контент в нескольких регионах. Он обрабатывает балансировку нагрузки, сжатие, кеширование и все, что вам может понадобиться от CDN.
  • Вы настраиваете CloudFront так, чтобы он «сидел перед» S3, поэтому он извлекает ваш контент из S3 и затем распространяет его во все свои доступные регионы. Как и в случае со всеми CDN, конечным результатом является быстрая загрузка вашего сайта независимо от его географической точки доступа.
  • Travis - это служба непрерывной интеграции ваших сборок. Новые сборки запускаются при отправке в репозиторий Git: создается одноразовая среда, выполняются ваши задачи, и в зависимости от того, как они завершаются, сборка считается успешной или неудачной. Он имеет бесплатный уровень для общедоступных репозиториев, поддерживает широкий спектр языков и требует всего 20 строк конфигурации для обработки загрузки сборок в S3.

Загрузка и настройка S3

Чтобы настроить корзину S3, войдите в консоль AWS и выполните следующие действия:

  1. S3 - ›Создать сегмент
    Выберите имя сегмента (ваше доменное имя, при желании с этапом, например dev-willmorgan.co.uk). Если у вас нет особых требований к региону AWS, вы можете использовать самый дешевый регион для хранения, который является стандартом США (us-east-1) на момент написания. Регион в большинстве случаев не имеет значения, поскольку CloudFront в любом случае распространяет ваш сайт локально.
  2. Выберите сегмент, перейдите в Свойства - ›Статический хостинг веб-сайтов, затем Включить хостинг веб-сайтов
    . Вы также можете получить доступ к свойствам, выбрав его в раскрывающемся меню, запускаемом справа. щелкнув имя сегмента.
  3. Вам нужно будет установить Индексный документ в индексный файл вашего веб-сайта, обычно index.html. Вам также, вероятно, следует установить документ об ошибке.
  4. По-прежнему в разделе Статический хостинг веб-сайтов, если у вас есть какие-либо правила перенаправления, вы можете настроить их в разделе Изменить правила перенаправления, используя несколько подробный синтаксис XML.
  5. Теперь перейдите в Свойства - ›Разрешения (это панель над статическим хостингом веб-сайтов). Хотя вы только что настроили S3 для работы как веб-сервер, доступ к файлам по-прежнему ограничен разрешениями, которые по умолчанию являются частными.
    Вам просто нужно изменить политику сегмента, чтобы по умолчанию все загруженные файлы были общедоступными. Это похоже на выполнение chmod в корневом веб-сервере вашего сервера.
    Выберите Изменить политику сегмента и разрешите доступ к действию s3:GetObject. Вы можете настроить свою собственную политику с помощью генератора или следовать приведенному ниже шаблону:
{
 "Version": "2012-10-17",
 "Id": "PublicBucketPolicy",
 "Statement": [
  {
   "Sid": "Stmt1482880670019",
   "Effect": "Allow",
   "Principal": "*",
   "Action": "s3:GetObject",
   "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*"
  }
 ]
}

После настройки этих параметров вам нужно будет сохранить каждый раздел. К счастью, AWS отлично справляется с проверкой вашей конфигурации при входе, поэтому вам не нужно позже отлаживать неправильную конфигурацию.

Наконец, загрузите созданный вами веб-сайт в S3. Мы займемся автоматическим развертыванием позже - есть открытый запрос на вытягивание, который немного упрощает автоматическую очистку кеша.

Обратите внимание на Конечную точку, указанную на панели Статический хостинг веб-сайтов, поскольку она вам понадобится позже.

Получение сертификата SSL

AWS предоставляет бесплатные сертификаты SSL, которые работают с браузерами, поддерживающими SNI. Вы, конечно, можете импортировать собственный SSL-сертификат, но для моих целей подойдет и бесплатный. При создании сертификата SSL подумайте, хотите ли вы поддерживать свой голый домен, а также субдомен www.

Если вы решите запросить сертификат с помощью диспетчера сертификатов, убедитесь, что ваши контактные адреса электронной почты по техническим / административным вопросам доступны, чтобы вы могли проверить запрос.

В общем, это простой процесс.

Конфигурация CloudFront

Интеграция S3 и CloudFront в основном безупречна.

Для настройки перейдите на страницу CloudFront в консоли AWS и выполните следующие действия:

Создайте новую рассылку Интернет. В разделе Настройки источника используйте Конечную точку, которую вы скопировали из статической настройки хостинга вашего сегмента S3. Многие другие руководства инструктируют это, не объясняя, почему - это потому, что если у вас есть правила перенаправления, настроенные с вашей корзиной S3, и вы указываете внутренний ресурс AWS S3, перенаправления больше не будут работать. Поэтому необходимо указать домен конечной точки веб-сайта, чтобы обеспечить работу функции перенаправления.

В разделе Настройки поведения кеша по умолчанию стоит выбрать Перенаправить HTTP на HTTPS и сузить Разрешенные методы HTTP - для статического веб-сайта GET и HEAD подойдут.

Важно отметить, что из-за надежного кэширования CloudFront вам нужно будет разработать механизм для обслуживания обновленных файлов - один из способов справиться с этим - определить кеш на основе строки запроса version, но вы всегда можете использовать другое имя файла, если хотите обновление в будущем.

Не забудьте установить флажок Автоматически сжимать объекты.

В разделе Настройки распространения вам необходимо:

  1. Задайте свои доменные имена в разделе Альтернативные доменные имена (yourdomain.com и, при необходимости, www.yourdomain.com).
  2. Настройте SSL, выбрав Пользовательский сертификат SSL, а затем выбрав сертификат, созданный или импортированный в Диспетчер сертификатов.
  3. Наконец, укажите корневой объект по умолчанию. Он должен совпадать с индексным документом вашего сегмента S3, обычно index.html. Здесь просто перенаправляются все запросы, когда клиент запрашивает URL-адрес вашего веб-сайта без указания пути.

На этом настройка S3 и CloudFront завершена. Это в основном конфигурация «установить и забыть» и обеспечивает хорошее разделение инфраструктуры, в отличие от привязки к программным файлам конфигурации, таким как .htaccess и httpd.conf.

На этом этапе статус вашего распространения CloudFront, скорее всего, будет Выполняется.

Запомните свое доменное имя CloudFront, так как оно понадобится в дальнейшем.

Прежде чем думать о переходе в рабочую среду, стоит подождать, пока статус не станет Развернуто. А пока Route 53 нуждается в настройке.

Конфигурация DNS с Route 53

На этом этапе у вас будет доменное имя CloudFront, например somewebsiteid.cloudfront.net. Пришло время связать этот домен с вашим основным доменом с помощью Route 53. Если вы разумны, я рекомендую сначала протестировать пробный поддомен, прежде чем отключать старые записи A / AAAA и продвигать свою версию AWS в рабочую среду.

Если у вас еще нет DNS, размещенного на Route 53, я должен сказать, что (скромные) дополнительные расходы того стоят. Это также требование, потому что эта конфигурация требует использования записи ALIAS, которая представляет собой особый вид записи DNS, которая работает аналогично CNAME, указывая ресурс AWS.

Вот шаги, предполагающие, что ваш DNS размещен на Route 53, и вы уже создали свои основные размещенные зоны:

  1. Если у вас уже есть наборы записей A и AAAA (то есть IPv4 и IPv6), вы захотите отредактировать наборы записей. В противном случае, если вы начинаете все сначала, вам нужно будет их создать.
  2. Для каждого домена, который вы хотите обслуживать свой веб-сайт CloudFront (ваш голый домен, например, mydomain.com и, возможно, его www-аналог, www.mydomain.com), вам нужно будет создать или обновить записи A your и AAAA, чтобы они были псевдонимами для ваш дистрибутив CloudFront, например:

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

Record   Domain             Alias Target
A      | mydomain.com     | somedistributionid.cloudfront.net
AAAA   | mydomain.com     | somedistributionid.cloudfront.net
A      | www.mydomain.com | somedistributionid.cloudfront.net
AAAA   | www.mydomain.com | somedistributionid.cloudfront.net

Имейте в виду, что, хотя в наши дни изменения DNS в Route 53 происходят практически мгновенно, CloudFront потребуется время, чтобы синхронизировать вашу корзину S3 в регионах ее распространения. Если вы видите, что эти странные вещи происходят сразу после того, как вы внесли эти изменения, дважды проверьте конфигурацию, но это может быть вопрос ожидания распространения изменений до тех пор, пока статус распространения CloudFront не станет Развернуто:

  • Если вы только что настроили сертификат SSL, вы можете увидеть ошибки сертификата в домене, для которого он был настроен.
  • Перенаправления на URL вашего сегмента S3

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

Оказывается, нужно было дождаться полного развертывания CloudFront. Урок, извлеченный для более важного веб-сайта для клиентов в будущем…

В конце концов, это случилось!

В итоге

Мне еще предстоит увидеть фактическую стоимость трафика для CloudFront и S3, но я получаю более быстрый, действительно статичный и действительно масштабируемый веб-сайт за небольшую часть стоимости управления моей собственной машиной.

Теперь у меня гораздо более легкая установка, что означает, что я могу запустить npm install, а затем запустить http-сервер в моем каталоге сборки. Гораздо более портативный.

Webpack вместе с HtmlWebpackPlugin обрабатывает объединение и вывод созданного веб-сайта. Затем Трэвис обрабатывает загрузку. Все, что мне нужно на моей машине, - это текстовый редактор - остальная часть конфигурации сборки отсутствует, что является преимуществом для случаев использования, когда я хочу поиграть на новой машине и быстро продвинуть ее.

Исходный код проекта открыт - вы можете просмотреть его здесь:
https://github.com/willmorgan/willmorgan.co.uk

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

Меня также можно нанять: jobs + medium [at] willmorgan.co.uk.