Заливаємо вебаплікацію на CDN від AWS
Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Вітаю, я Сенчук Роман, працюю на посаді Solution Architect Associate в Vodworks. Цей тайтл не часто зустрічається в українських компаніях, є проміжним етапом між Tech Lead та Solution Architect. В основному маю справу з AWS та GCP.
У цій статті хочу коротко розказати про те, як захостити свою вебаплікацію на CDN від Amazon. Це може бути цікаво всім, хто хоче покращити доступ до свого ресурсу, а саме прискорити завантаження статичного контенту користувачами.
Часто оптимальним рішенням є використання Мережі Розповсюдження Контенту (CDN). Статичним контентом тут може бути як збілджена JavaScript Аплікація (React чи Angular), так і зображення чи статичний HTML. У цій статті оперуватимемо AWS S3 (для збереження та хостингу), CloudFront (як CDN) та функціоналом DNS-провайдера (може бути будь-який), у нашому випадку — це CloudFlare. Також використовуватимемо TLS/SSL сертифікат від Cloudflare для того, щоб ресурс працював на HTTPS (з підтримкою Cloudflare «Full Strict» режиму).
Завдання здається простим і є багато ресурсів з висвітлення подібного, проте, як виявилось, є багато підводних каменів, і аналогічний контент часто застарілий.
Тут не будемо розглядати створення та білд JS аплікації, створення S3 бакета (або ж «відра» українською), залиття контенту в бакет, чи реєстрації DNS-домену.
HTTP на S3
Одже, створюємо S3 бакет та заливаємо збілджений код туди, в корінь. Проте тут є нюанс — обмеження від Amazon: бакет повинен мати ім’я таке ж, як домен (піддомен). Наприклад,
якщо планується розмістити білд на домені my.react-app.com, то й назва бакету повинна бути my.react-app.com.
Далі у властивостях бакету (вкладка Properties) потрібно ввімкнути Static website hosting. Нижче, в полі Index Document, потрібно вказати index файл (index.html зазвичай).
Зберігаємо налаштування та переходимо до вкладки доступів (Permissions).
Тут нам потрібно вимкнути блокування доступів, якщо воно активне (Block public access).
В Bucket Policy (Політика доступу) нам потрібно надати доступ для CloudFront. Щоб спростити задачу, надамо доступ всім сервісам AWS (потім це можна переналаштувати).
В полі для JSON потрібно скопіювати наступне:
{ "Version": "2012-10-17", "Id": "Policy1638279142165", "Statement": [ { "Sid": "Statement1", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::my.react-app.com/*" } ] }
де в рядку «Resource»: «arn:aws:s3:::my.react-app.com/*»
«my.react-app.com» потрібно замінити ім’ям цього бакета.
Зберігаємо налаштування та намагаємось доступитись до аплікації через HTTP. Для цього на вкладці властивостей бакету (Properties) в полі Static website hosting переходимо по лінку, вказаному під пунктом «Bucket website endpoint».
На цьому етапі ми повинні мати доступ до нашого ресурсу під згенерованим доменом через HTTP. Якщо з цим виникли проблеми, то варто спробувати пройтись по попередніх налаштуваннях ще раз, перш ніж рухатись далі.
SSL/TLS сертифікат
Щоб ресурс працював через HTTPS, потрібно використати сертифікат, згенерований для потрібно домену. Якщо на AWS у вас вже є сертифікат (наприклад, якщо домен на Route 53), цей крок можна пропустити.
Для менеджменту сертифікатів в AWS є сервіс Certificate Manager (ACM). Тож заходимо туди та обираємо опцію запиту сертифіката (Request certificate). Далі обираємо опцію публічного сертифікату (Request a public certificate).
Тут є перший нюанс: для того, щоб сертифікат можна було використовувати в Cloudfront, його потрібно додавати саме в зоні доступності «N.Virginia» (us-east-1), що зовсім не інтуїтивно.
Деталі — тут.
Там заповнюємо назву домену:
Та спосіб валідації:
Обираємо DNS-валідацію, адже саме цей спосіб є рекомендованим. Натискаємо Request, щоб створити запит на отримання сертифікату.
Після цього сертифікат з’явиться в списку сертифікатів зі статусом «Очікує валідації» (Pending validation). Щоб валідувати його, потрібно створити DNS-запис згідно згенерованих значень:
Ми підтвердили приналежність поточного ресурсу до вказаного домену (а значить і сертифікату).
Тож додаємо відповідний CNAME запис до DNS (в нашому випадку в Cloudflare):
Через певний час наш сертифікат буде валідованим та отримає статус «Issued».
Cloudfront
Cloudfront — це CDN сервіс від Amazon, який за допомогою глобально розподілених проксі-серверів кешує контент, у нас — складові аплікації. Тож нам потрібно налаштувати дистрибутив для розподілення з джерелом даних у попередньо створене S3 відро (bucket).
В Distributions обираємо Create та заповнюємо Origin domain.
Тут ще один зовсім не інтуїтивний момент: коли ми вводитимемо назву бакета, нам підтягнеться наш S3 ресурс. Проте це не те, що нам потрібно.
В це поле потрібно вставити URL, за яким ми раніше через HTTP мали доступ до нашого бакету. Щоб його отримати, йдемо до «Властивостей» нашого бакету (Bucket Properties) та копіюємо адресу з поля website endpoint. Вставляємо його без http:// та без слешу в кінці.
До прикладу, в нашому випадку, в полі Origin domain при створенні дистрибутива у нас буде підказка:
«my.react-app.com.s3.amazonaws.com» (закінчується «s3.amazonaws.com» )
а потрібно:
«my.react-app.com.s3-website-eu-west-1.amazonaws.com»
Далі шукаємо поле Alternate domain name. Тут потрібно вказати домен (назву бакету), наприклад my.react-app.com.
Та обрати створений вище сертифікат.
Всі інші поля залишаємо без змін, та створюємо дистрибутив.
Спочатку дистрибутив отримає статус «deploying», і коли стане готовим до використання, статус зміниться на «Enabled».
На цьому етапі наш ресурс повинен бути доступний через потрібний HTTPS на CDN Amazon. Щоб переконатись в цьому, потрібно перейти на URL, вказаний в деталях новоствореного дистрибутиву:
Фінальний штрих
Тепер, щоб дана аплікація працювала під нашим доменом, потрібно створити відповідний DNS запис, в якому ми впишемо, що за контентом для вказаного домену потрібно звернутись до налаштованого вище дистрибутиву Cloudfront (Distribution domain name). Оскільки дистрибутив доступний по URL, використаємо той же CNAME запис.
Щоб DNS запис вступив в дію, потрібен певний час.
DNS провайдер Cloudflare
Якщо все пройшло добре, та всі інші DNS записи відповідають вимогам end-to-end HTTPS шифрування то можна ввімкнути режим «Full (strict)».
Index файл не знайдено
Якщо на якомусь етапі замість аплікації відкривається XML з переліком файлів у відрі, то ймовірно, що cloudfront не знає, який індекс файл використовувати. Щоб виправити це, можна налаштувавши шлях до індекс файлу (Origin path) в Cloudfront дистрибутиві.
19 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів