Все записи автора Maximus

Как использовать AWS S3 для статических сайтов?

Всем привет! Я вернулся к ведению блога! 🙂

Итак, сегодня мы рассмотрим пошагово настройку хостинга сайтов на серверах AWS. Подробно о плюсах и минусах я писал здесь — HTML-хостинг сайта на AWS S3 Amazon.

Настройка бакета (хранилища) статического сайта

Создание хранилища

  • Для начала логинимся в Amazon AWS.
  • Затем создаем хранилище. Переходим в сервис S3 и кликаем «Create bucket» для создания хранилища.
  • Переходим на страницу создания бакета и вносим свои название и регион (которые нам нужны)
  • Все настройки ниже оставляем стандартными и нажимаем кнопку «Create bucket»
  • У нас должен появиться в списке бакет

Настроим политику безопасности

  • Теперь настроим наше хранилище как сайт. Для этого кликаем таб Permissions и переходим на страницу редактирования политик. Находим внизу поле «Bucket policy», кликаем Edit и вставляем туда свой конфиг политики.

    Обратите внимание на строку «StringNotLike». Это массив нежелательных ботов для вашего сайта. Вы можете в это массив по примеру вставить своих ботов, чтобы они не краулили ваш сайт.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::shoot.click/*",
            "Condition": {
                "StringNotLike": {
                    "aws:UserAgent": [
                        "Baiduspider*",
                        "Sosospider*",
                        "Sogou*"
                    ]
                }
            }
        }
    ]
}

Нажимаем кнопку Save changes. Если получаем такую ошибку, значит надо отредактировать политику доступа.

Для этого отменяем редактирование политики бакета, на странице Permissions находим блок с Block publick access (bucket settings) и снимаем галочку, тем самым выключая блок. Затем пытаемся снова вставить код в Bucket policy.

  • Сохраняем политику. Возле названия бакета должен появиться лейбл Publicly accessible.

Настроим хостинг

Чтобы превратить бакет в хранилище хостинга, нужно перейти в пункт Properties -> Static website hosting. Это в самом низу страницы.

Протокол указываем http.

Сохраняем настройки.

Настройка DNS-записей

Для того, чтобы настроить DNS для нашего бакета, нужно перейти в панель сервиса Route 53. Опишу процесс пошагово:

  1. Создать хостинговую зону.
  2. Создать Record Set для зоны.
  3. Прописать NS-записи в панели регистратора.

Шаг 1 — создание Hosted zone

В панели Route 53 кликаем «Create hosted zone».

Далее в поле названия вписываем имя домена и кликаем Create hosted zone.

У нас должны появиться две записи:

Шаг 2 — Создание Record Set для зоны

Для этого кликаем кнопку Create record в панели зоны.

Переходим в панель создания записей для зоны.

  1. Включаем пункт «Alias».
  2. Выбираем из выпадающего списка «Alias to S3 website endpoint»
  3. Из появившегося внизу списка выбираем зону, в которой создали бакет.
  4. В поле ниже должен подтянуться endpoint нашего бакета.
  5. Кликаем Create records.

Такие же манипуляции делаем для www-домена.

Шаг 3 — Редактирование NS-записей

В панели Route 53 копируем ns-записи для домена и вставляем их в панели регистратора.

Добавление файлов в корень бакета S3

Открываем наш бакет и перетаскиваем файлы в корень бакета.

Если мы все правильно сделали, то у нас должно все получиться. Например: http://shoot.click/

Стоит ли строить PBN? Результаты эксперимента по простановке ссылок

Думаю, многие из вас задаются вопросом, как вычислить стоимость создания PBN-сетки и её рентабельность. Т.е. проще говоря — окупится ли PBN, и сколько надо сайтов, чтобы она окупилась?

Если вы продвигаете свой проект или клиентский, вам надо исходить из бюджета, выделенного на эти проекты. Когда можно задуматься о построении своей PBN-сетки? Специалисты утверждают, что в таких случаях, когда стоимость ссылки в нише выше, чем создание сайта под такую ссылку. Это основное экономическое обоснование. К нему можно еще добавить, в зависимости от ниши.

Давайте проведём простой математический расчёт. Допустим, стоимость качественной анкорной ссылки на вашу страницу равна $300 с размещением гостевого поста. Что надо сделать?

  1. Проанализировать топ по запросу, по которому вы хотите продвигаться.
    1. Учесть количество ссылок на страницу в топ-1;
    2. Учесть качество этих ссылок, т.е. узнать средний DA, CF/TF (медиану).
  2. Рассчитать количество ссылок для своей страницы, исходя из результатов аналитики топа, т.е. взять за основу такое же качество ссылок, как у конкурентов и добавить пару штук.

Например, по запросу «натяжные потолки Киев» у нас такие результаты

Как видим, в ТОП-1 страница с 47 доменами в ссылочном профиле страницы и 84 ссылки. Т.е. в среднем по 2 ссылки с домена.

Чтобы вам выйти в топ-1 по этой фразе, надо разместить на свой домен 85 ссылок с 48 доменов такого же качества.

Понятное дело, это топорный расчёт и на ранжирование так прямо не влияет, однако исходные предпосылки должны быть такими.

Итак, что дальше?

Теперь надо узнать стоимость ссылки в этой нише на свою статью. Если она превышает $300-$400, вы можете задуматься о построении своей собственной сетки или заказать у специалистов. При этом вы можете

  • Быть уверенным, что ссылка размещена и никуда не пропадёт;
  • По возможности проставлять ссылки с PBN с повторных постов (до 3 ссылок с сайта на 1 проект);
  • Расширять семантическое ядро PBN-сетки и проставлять ссылки на смежные проекты.

Т.е. вы можете заказать сетку, к примеру, из 50 доменов, потратить на неё $10K и в дальнейшем развивать её, наращивая ссылочную массу и семантическое ядро. Вы получите в свои руки инструмент, с помощью которого сможете продвигать не 1 проект, а ряд проектов смежных тематик. И, конечно, у вас в руках будет возможность проставлять хорошие эффективные ссылки!

Эксперимент с простановкой ссылок и редиректов

В июле-августе 2019 года я проводил эксперимент по простановке ссылок с PBN и, как альтернатива, простановка редиректов.

Гипотеза

Мы хотели проверить две гипотезы:

  • Насколько эффективно работают анкорные ссылки со страниц дропов?
  • Насколько эффективен 301 редирект?

Эксперимент с простановкой ссылок с дропов

Исходные данные

Характеристики дропов, с которых проставил анкорную ссылку

TFCFRefDomBacklinks
domain1.com171525125
domain2.com 15153587
domain3.com 0476150
domain4.com 23131389

А также есть 2 страницы 2-х разных сайтов, по которым я собрал по топ-20 фраз и поставил пробивку позиций раз в 3 дня.

На этих дропах контентщики подготовили посадочные статьи для ссылок.

Выполнение задачи

  1. Я собрал семантику для страниц, по топ-20 фраз и отсортировал их по частотности. Взял высокочастотные.
  2. Установил мониторинг позиций по фразам с привязкой к статьям.
  3. С 4-х дропов проставил анкорные ссылки с постов, с первого абзаца статьи дропа и с preview главной.

Результаты простановки сылок с дропов

Страница 1

Параметры домена, на который проставляем ссылки
  • Рост позиций замечен по 5 ключевым фразам. 
  • Диапазон роста: 1 позиция.
  • 6 ключевых фраз не показали роста по позициям.
  • 9 ключевых фраз опустились в ранжировании с -1 по -5 позиций.
Динамика роста позиций 1 страницы

Страница 2

Параметры экспериментального домена
  • Рост позиций замечен по 16 ключевым фразам. 
  • Диапазон роста: 1-100 позиций.
  • 2 ключевых фразы не показали роста по позициям.
  • 2 ключевых фразы опустились в ранжировании с -1 по -3 позиции.
Динамика роста позиций 2 страницы

Эксперимент с 301 редиректом с дропа на страницу

Исходные данные

Есть 4 дропа с такими характеристиками:

TFCFRefDomBacklinks
domain5.com131640225
domain6.com 12161102090
domain7.com 10842217
domain8.com 36107928

Кроме этого, в у нас были еще 2 страницы: 1 страница — обзор товаров, 2 — главная страница.

На наших 4-х дропах был контент, но я снял весь контент и делал редирект через .htaccess-файл:

Выполнение задачи

  1. Собрал семантику для страниц, взял топ-20 высокочастотных фраз.
  2. Установил мониторинг позиций по фразам с привязкой к страницам.
  3. Проставил четыре 301 редиректа на две страницы, по 2 на каждую.
htaccess-редирект

Результаты простановки 301 редиректа с дропов

Страница 1

Параметры экспериментального домена
  • Рост позиций замечен по 7 ключевым фразам. 
  • Диапазон роста: 1-2 позиции.
  • 5 ключевых фраз не показали роста по позициям.
  • 8 ключевых фраз опустились в ранжировании с -1 по -3 позиции.
Динамика позиций во время простановки 301 редиректа на страницу-обзор

Страница 2

Параметры экспериментального домена
  • Рост позиций замечен по 9 ключевым фразам. 
  • Диапазон роста: 1-69 позиций.
  • 7 ключевых фраз не показали роста по позициям.
  • 4 ключевые фразы опустились в ранжировании с -1 по -42 позиции.

Однозначно сказать, что позиции выросли из-за проставленного редиректа нельзя, так как рост видно до простановки (6 августа), во время простановки и после простановки редиректа.

Динамика позиций во время простановки 301 редиректа на главную страницу

Вывод по эксперименту

Итак, учитывая результаты, мы можем сделать вывод:

  • Ссылки с PBN-сайтов работают.
  • 301 редирект не настолько эффективен, как простановка анкорной ссылки.

Вы можете присмотреться к результатам этого эксперимента и сами проектировать свои сетки, количество и качество.

Как быть с размещением сеток на сервере? Обзор методов хостинга сеток

Сколько методов хостинга сеток вы знаете? А сколько существует на самом деле? Как раз об этом пойдет речь.

Чтобы вы имели представление, что такое хостинг, оставлю здесь цитату:

Хостинг – это услуга предоставления ресурсов на сервере для размещения информации (чаще всего файлов сайта) в сети Интернет. Обычно под хостингом подразумевают услугу размещения файлов сайта на заранее настроенном сервере с программным обеспечением, необходимым для обработки запросов к этим файлам и сопутствующими сервисами (веб-сервер, сервер баз данных, DNS-сервер, PHP-обработчик, FTP-сервер, почтовый сервер).

В моем опыте работы я столкнулся с 4 методами хостинга сеток.

1. Хостинг сеток, используя Cloudflare
2. HTML-Хостинг на AWS
3. Хостинг с использованием shared-серверов
4. Хостинг через AWS Route 53 + AWS Lightsail

Сколько все это стоит? И насколько полезно? Судите сами, смотря какие цели вы преследуете при построении сетки.

Хостинг via Cloudflare

Этот вид хостинга сеток самый распространённый. Нет ничего сложного в том, чтобы скрыть сетку за аккаунтами этой известной CDN, более того, клаудфлейр используют миллионы сайтов. Чуть раньше Джонсон писал здесь, как настроить Cloudflare для чайников.

Эта глобальная сеть серверов на данный момент присутствует в 193 городах, о чём они сообщают в своей статье — Cloudflare Global Network Expands to 193 Cities.

Многие позиционируют клауд как надёжную отказоустойчивую сеть доставки контента. Однако так ли это? События 2 июля 2019 года надолго запомнились всем пользователям Cloudflare, когда все сайты, которые обслуживались Cloudflare, стали отдавать 502 ошибку.

Вот что по этому поводу пишет Джон Грэм-Камминг на блоге Cloudflare:

On July 2, we deployed a new rule in our WAF Managed Rules that caused CPUs to become exhausted on every CPU core that handles HTTP/HTTPS traffic on the Cloudflare network worldwide. We are constantly improving WAF Managed Rules to respond to new vulnerabilities and threats. In May, for example, we used the speed with which we can update the WAF to push a rule to protect against a serious SharePoint vulnerability. Being able to deploy rules quickly and globally is a critical feature of our WAF.

Unfortunately, last Tuesday’s update contained a regular expression that backtracked enormously and exhausted CPU used for HTTP/HTTPS serving. This brought down Cloudflare’s core proxying, CDN and WAF functionality. The following graph shows CPUs dedicated to serving HTTP/HTTPS traffic spiking to nearly 100% usage across the servers in our network.

This resulted in our customers (and their customers) seeing a 502 error page when visiting any Cloudflare domain. The 502 errors were generated by the front line Cloudflare web servers that still had CPU cores available but were unable to reach the processes that serve HTTP/HTTPS traffic.

John Graham-Cumming
Загрузка процессора во время инцидента

Собственно, когда упала сетка сайтов, которая использовала клауд, команда PBN-разработки чувствовала себя очень неуютно. Более 12 млн сайтов были недоступны 27 минут из-за релиза неверного регулярного выражения.

Однако этот инцидент не повлиял особо на позиции сайтов или на возможность обнаружения сетки, т.к. в это время полмира валялось.

Впрочем, ещё один из минусов этой CDN — одинаковые ns-записи в пределах аккаунта в бесплатной версии. Поэтому, чтобы минимизировать вероятность конкурентного расследования, следует использовать десятки различных аккаунтов.

Плюсы использования Cloudflare:

  • Сетке можно затеряться среди миллионов сайтов;
  • Лёгкость в настройке для небольших проектов;
  • Firewall & Black List IP / UA
  • Free SSL
  • Бесплатно.

Минусы использования Cloudflare:

  • Одинаковые NS-записи в пределах 1 аккаунта в бесплатном тарифном плане;
  • 3 сторона: усложение системы делает её уязвимее и зависимее от внешних факторов.

HTML-хостинг сайта на AWS S3 Amazon

Довольно-таки необычный вид хостинга на данный момент. Мало кто им пользуется, однако этот способ удобный для хостинга малофункциональных контентных блогов. Amazon предоставляет сервисы хранилищ данных и файлов S3.

Какой принцип работы?

  1. Создаём сайт на локалке/поддомене, короче в любом месте на любом домене;
  2. Конвертируем сайт в набор статических файлов;
  3. Загружаем набор файлов в бакет;
  4. Создаём Hosted Zone в Route53;
  5. Прописываем ns-записи на стороне регистратора.

Этот способ отличается от первого тем, что здесь уже не обойтись бесплатным аккаунтом. Придётся платить. По факту AWS S3 выступает как хостинг файлов сайта.

Одно отличие в том, что тарификация хостинга высчитывается в зависимости от количества запросов.

Route53 DNS-запросы0.40
1st 25 Route53 HostedZone0.50
Additional Route53 HostedZones 0.10
AWS Data Transfer — per GB0.02
Amazon S3 Requests-Tier2 — per 10K GET requests0.004

Стоимость хостинга 50 сайтов достигает около $15/месяц.

Однако редактирование контента невозможно без инспектирования кода статических файлов. Это сложно, поэтому приходится редактировать всё на движке и конвертировать/заливать заново.

Этот метод подойдёт для хостинга большой статической сетки сайтов, которая не обновляется или обновляется в полуавтоматическом режиме с настройкой автостатики и трансфера файлов на амазон.

Плюсы

  • ns-записи, выдаваемые Route53-панелью уникальные для каждого сайта;
  • Трафик проксируется через трастовые сети Амазона;
  • Хостинг файлов вирусоустойчив, т.к. статичен;

Минусы

  • Нельзя редактировать сайт в онлайн-режиме.

Хостинг с использованием shared-серверов

Принцип хостинга состоит в скрытии оригинального сервера от источника через внешний сервер с уникальным ip-адресом.

Для того, чтобы его реализовать, необходимо иметь такие ресурсы:

  1. Main Server — сервер, на котором размещаются проекты
  2. Shared Server — сервер с конфигами проксирования.

Система оправдывает себя, если необходимо иметь внешние кастомные IP-адреса для проксирования. Профит в том, что под контролем основные системные узлы.

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

Стоимость такой системы зависит от нескольких факторов: геолокация серверов, количество сайтов на 1 IP.

Стандартная стоимость 1 шаред-сервера равна $5/мес. Если на 1 шаред вешать 5 сайтов, то стоимость сетки в 50 сайтов будет равна $50. Есть возможность такую систему сделать дешевле, но об это позже.

Плюсы

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

Минусы

  • Относительная дороговизна системы;
  • Потребность в навыках сетевого администрирования и конфигурирования серверов.

Хостинг через AWS Route 53 + AWS Lightsail

Это моя собственная разработка, т.е. я нигде её не видел. Эта система включает в себя характеристики двух предыдущих методов, а именно:

  • Кастомные ns-записи для каждого домена;
  • IP сайта скрываются за сетью серверов Amazon;
  • Конфигурирование промежуточных серверов.

Стоимость такой системы дешевле, чем проксирование через shared-сервера, но для того, чтобы в этом разобраться, надо иметь навыки администрирования Amazon AWS.

Какой принцип работы?

  1. Создаём сетевую инфраструктуру в AWS Lightsail;
  2. Создаём Hosted Zone в Route53;
  3. Загружаем конфиги на VPS-сервер, который мы создали в шаге 1;
  4. Апдейтим ns-записи на стороне регистратора.

Теперь перейдём к стоимости.

Route53 DNS-запросы0.40
1st 25 Route53 HostedZone0.50
Additional Route53 HostedZones 0.10
AWS Data Transfer — per GB0.02
Amazon S3 Requests-Tier2 — per 10K GET requests0.004
Elastic Compute Cloud per Elastic IP 0.005
Amazon Lightsail Bundle:0.5GB / Hour0.0047
Amazon Lightsail LoadBalancer / Hour0.0242

За хостинг таким методом 280 сайтов нужно отдать примерно $70.

Плюсы

  • Уникальные ns для каждого домена;
  • Скрытие origin-сервера через сети Amazon.

Минусы

  • Сложность в настройке;
  • Не бесплатно.

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

5 / 5 ( 2 голоса )