company_banner

Статические сайты в облачном хранилище

  • Tutorial
pr-424-2-1

Большинство современных веб-сайтов являются динамическими. Их страницы формируются на стороне сервера, а затем отображаются в браузере пользователя. Многие такие сайты функционируют на основе простых и удобных CMS (систем управления контентом) в состав которых, как правило, входит WYSIWYG-редактор, простой и интуитивно понятный. При всей очевидной простоте при работе с динамическими сайтами возникает целый ряд неудобств.


Функционирование динамического сайта обеспечивается «связкой» из веб-сервера, приложения для генерации страниц и базы данных. Взаимодействие всех этих компонентов нередко сопряжено с серьезными затратами системных ресурсов. Чтобы снизить нагрузку и уменьшить время генерации страниц, используется кэширование, но его можно использовать не всегда и не везде. Обычно кэшируется контент, имеющий большой объем — например, графика. Также кэширование необходимо для минимизации числа запросов к базе данных.

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

В связи со всеми описанными неудобствами и трудностями в последнее время существенно возрос интерес к статическим сайтам. Статический сайт представляет собой набор файлов (HTML, JS, графика, шрифты), размещенных на сервере. Для его обслуживания не требуется больших затрат системных ресурсов; с резервным копированием тоже не возникает никаких трудностей. Страницы для таких сайтов можно создавать и редактировать в любом текстовом редакторе.

Для объединения контента с шаблонами можно использовать так называемые генераторы статических сайтов. Генераторов существует очень много (на одном только GitHub их опубликовано несколько десятков). Наиболее широко распространенными и популярными являются Hyde, написанный на Python, а также Jekyll и MiddleMan, написанные на Ruby.

Обзор всех существующих генераторов статических сайтов выходит далеко за рамки этой статьи; всех заинтересованных читателей отсылаем к подробной сравнительной таблице.

Существует целый ряд категорий сайтов, которые гораздо удобнее делать статическими: сайты-визитки, блоги, каталоги товаров, онлайн-документация к программным продуктам и техническим устройствам. Для таких сайтов может потребоваться динамическая часть — комментарии, поиск, личный кабинет пользователя, создание страниц, но она вполне может быть реализована с помощью сторонних инструментов, прекрасно справляющихся с возлагаемыми на них задачами.

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

Преимущества



В качестве площадки для статических сайтов наше хранилище обладает следующими преимуществами:
  • указание индексного файла;
  • указание страницы ошибки;
  • листинг директории (plain и JSON) c возможностью задания собственного CSS;
  • просмотр статистики по запросам;
  • управление заголовками для кэширования;
  • создание страниц, на которых пользователи могут загрузить на сайт свои файлы;
  • организация просмотра изображений в виде фотогалереи;
  • прикрепление доменов второго уровня;
  • низкая стоимость использования — от 1 рубля в месяц.


Размещение сайта: пошаговая инструкция



Шаг 1: создаем публичный контейнер



Создать сайт на основе облачного хранилища достаточно просто. Войдем в панель управления под своей учетной записью, выберем в главном меню пункт «Облачное хранилище» и создадим публичный контейнер:



Шаг 2: настраиваем специальные страницы



Теперь нужно настроить специальные страницы — индексный файл и файл ошибки. Для этого нажмем на значок Создать сайт на основе облачного хранилища достаточно просто, расположенный справа от имени контейнера, и выберем в открывшемся меню соответствующий пункт:

Создать сайт на основе облачного хранилища достаточно просто

Откроется окно настройки специальных страниц:

Создать сайт на основе облачного хранилища достаточно просто

В поле «Индексный файл» указываем путь к файлу «index.html», который будет загружаться при обращении пользователя напрямую к какой-либо директории. Путь к индексному файлу может быть абсолютным и относительным (без символа / в начале). Абсолютный путь указывает на строго определенное расположение файла, вне зависимости от текущей рабочей папки или других обстоятельств. Он всегда начинается с корневого контейнера. При указании относительного пути поиск осуществляется не с корневого каталога, а с конца. Сначала система будет искать файл «index.html» в ближайшей к концу пути папке; если в ней такого файла нет, то будет пользователю будет отдан соответствующий файл из корневого каталога. Создадим в текстовом редакторе файл и напишем в нем, например, следующий текст:

<html>
  <body>
    <h1>Hello, world!</h1>
  </body> 
</html>


Затем сохраним его под именем «index.html». Загрузим его в контейнер, а затем выберем в качестве индексного. Если мы введем в строку браузера адрес типа «http://xxxxx.selcdn.ru/site/», то мы увидим индексную страницу с текстом «Hello, world!», сохраненным нами в соответствующем файле. Для индексной страницы можно создать файл стилей CSS (путь к нему указывается в поле «Файл стилей листинга»).

В поле «Файл ошибки» прописываем путь к файлу, на который будет отдан пользователю в случае, если тот запросит несуществующую страницу (ошибка 404). Создадим в текстовом редакторе файл с текстом «Page not found» и сохраним его под именем «error.html». Затем укажем его в качестве файла ошибки. Если мы укажем путь в адресной строке браузера путь к заведомо несуществующей странице (например, «http://xxxxx. selcdn.ru/site/1»), то мы будем перенаправлены на указанную нами страницу ошибки, и на экране будет отображен текст «Page not found». Странице ошибки 404 также можно придать оригинальное оформление. Вот что видят, например, пользователи, пытающиеся попасть на несуществующую страницу на сайте облачного хранилища — http://storage.selectel.ru/404.html

В поле «Файл ошибки» можно также указывать ссылку на любой внешний ресурс (если, например, будет указана ссылка на сайт «http://example.com», то при ошибке 404 пользователь будет перенаправлен именно на него).

Шаг 3: прикрепляем домен



Теперь нужно прикрепить к контейнеру домен. В том же меню выбираем пункт «Привязать домен»:

Теперь нужно прикрепить к контейнеру домен.

К одному контейнеру можно прикрепить до пяти доменов. Все хранимые в контейнере файлы будут доступны по имени прикрепленного домена. Если, например, к контейнеру «my_images» привязать домен «images.example.com», то все файлы из этого контейнера будут доступны по адресу «http://images.example.com». Прежде чем прикреплять домен, нужно обязательно внести в DNS необходимые записи (подробнее см. в панели управления)

Прикрепление доменов второго уровня



Мы наконец-то сделали-то, о чем нас давно просили многие клиенты: к контейнерам теперь можно прикреплять домены второго уровня. Для этого в DNS нужно внести А-запись (для IPv6-адресов — АААА-запись), ссылающуюся на адреса, указанные в панели управления.

Шаг 4: загружаем файлы



Задав все основные настройки, поместим в контейнер файлы для будущего сайта. Вот и все — сайт готов к работе!

Управление HTTP-заголовками



В облачном хранилище предусмотрена возможность управления http-заголовками для кэширования. Выберем в меню контейнера пункт «HTTP-заголовки». Нам нужно обратить особое внимание на заголовки Expires и Cache-control. С помощью заголовка Expires можно установить срок, в течение которого браузер будет кэшировать данные. В поле Expires вводится дата предполагаемого истечения актуальности данных в формате " день недели, число месяц год часы: минуты: секунды GMT, например: «Tue, 31 Jan 2012 15:02:53 GMT». После указанной даты кэширование осуществляться не будет, и с сервера будут загружены обновленные данные.

Управление кэшированием веб-страниц осуществляется с помощью заголовка cache-control, который может принимать следующие значения:

  • no cache — полный запрет кэширования (используется в часто обновляемых страницах);
  • public — разрешение кэширования как локальным клиентом, так и прокси-сервером;
  • private — разрешение кэширования только локальным клиентом;
  • max-age — использовать кэшированный документ в течение заданного времени в секундах;
  • no-store — запрет на кэширование страницы, содержащей приватные данные.


Стоимость



Помимо простоты, несомненным преимуществом использования облачного хранилища для хостинга статических сайтов является низкая стоимость хранения информации. Проиллюстрируем это конкретным примером: сам сайт хранилища в общей сложности «весит» три мегабайта; он обходится нам вместе с трафиком всего в 3 (!) рубля в месяц.

Приглашаем всех желающих попробовать создать собственный сайт на базе хранилище прямо сейчас.
Каждый пользователь при регистрации получает на счет 10 рублей. Этой суммы вполне достаточно для того, чтобы хранить 1 Гб данных (и скачать 1 Гб данных) в течение 1 месяца.

Читателей, которые по тем или иным причинам не могут комментировать посты на Хабре, приглашаем в наш блог.
Selectel
147,54
ИТ-инфраструктура для бизнеса
Поделиться публикацией

Комментарии 46

    –34
    Хабр не для копипаста
      +19
      Обратите внимание на то, что это корпоративный блог.
      +4
      К вам на сервер можно заливать автоматически? По API или еще как то?
        +2
        Работать с облачным хранилищем можно при помощи браузера (через панель управления услугами Селектел), любого FTP-клиента или OpenStack Swift-совместимого программного обеспечения. Количество подходящего для работы с облачным хранилищем ПО насчитывает десятки приложений под любые операционные системы. Специально для iPhone нами было создано мобильное приложение Cloud Storage (доступно в App Store).

        storage.selectel.ru/vozmozhnosti/sposobi-dostupa/
          +1
          Конечно можно. Через общераспространенное API swift, частично s3 и еще через некоторые наши плюшки :-)
            +1
            Хочу как диск подмонтировать в вин/линуксе (как блочное хранилище желательно) — есть простые решения?
              +3
              Хранилище является объектным, напрямую работать «блочный» способом нельзя, но есть ряд программ которые эмулируют блочную работу, только у них есть свои недостатки и ограничения. Например, s3ql.
                0
                Спасибо за ссыль. Сyberduck не тестировали под вин?
                  +2
                  Работает. Для быстрой настройки у нас сделан специальный профиль, который можно скачать из панели управления.
            +1
            дык ncftp / scp не?
            0
            Туда бы еще SSI (разумеется, no-exec) :)
              +1
              А что полезного можно реализовать на SSI?

              Я как-то пробовал сайт-визитку делать, так задолбался и переехал на phtml.
                +2
                Полезного, ну например вынести меню, шапку, футер в отдельный файл.
                  +3
                  Вынесите его в любом темплейтном движке, который нравится, откомпилируйте его на своей машине, получите готовые html и заливайте, не?
                    0
                    еще большая экономия траффика на изменение-загрузку и на хранение.
                  0
                  Вы просто готовить не умеете :)

                  Пример: скажем, готовите вы сайт текстового нединамического свойства, скажем, с документацией на Apache. Вы вынесли header и footer в отдельные файлы, отрендерили содержимое сайта в виде html страниц, указали в каждой в начале и конце теги включения header-а и footer-а — вот вам и страницы с оформением, притом не пришлось в каждую из страничек добавлять содержимое header-а и footer-а.

                  А самое приятное — DDoS этот сайт, случись нужда, переживет легко, и по цене отдачи трафика, что будет даже и недорого. Процессор оплачивать не придется :)

                  Рендерить будете скриптом на локальной машине, и им же, через API Selectel-а, зальете странички в облако.
                    0
                    Я как раз выжал из SSI всё. Но когда мне понадобилось динамически содержимое строить парся статику тут уж SSI отдыхал.
                +3
                В копилку статикогенераторов:
                thewml.org/

                уже сто лет как начал пользоваться (это, наверное, родоначальник, раньше всех других появился) — простой, при необходимости — хорошо расширяемый, ну и довольно удобно.
                  0
                  А что по ширине каналов?
                    +1
                    Более 10 аплинков, подключенных 10Gbit интерфейсами, думаю, достаточно =)
                      0
                      Чудно, на днях потестируем бэкапы.
                    0
                    SSI поддерживается?
                      +2
                      Нет, не поддерживается.
                      +1
                      получает на счет 10 рублей. Этой суммы вполне достаточно для того, чтобы хранить 1 Гб данных (и скачать 1 Гб данных) в течение 1 месяца.

                      А на storage.selectel.ru/stoimost/:
                      Например, этого хватит_чтобы 3 месяца хранить 1 Гб данных и скачать 1 Гб данных.
                        0
                        Строго говоря, оба утверждения истинны.
                          0
                          если уж совсем строго говоря, то если истинно второе, то первое тоже истинно. из истинности первого, истинность второго не следует.
                        +3
                        Немного оффтоп, но я бы еще добавил в список популярных статикогенераторов Harp.js

                        Достаточно новый, но быстро развивающийся проект. Может кому пригодится.
                          +1
                          Вообще, здорово что вы разрешаете привязать домен второго уровня к хранилищу. У амазона, чтобы так сделать c S3, надо начать платить за их Rote53. Можно конечно схитрить с wwwizer.com, но ваше решение красивше.

                          Единственный вопрос: вы не дружите с яндексом? Периодически метрика шлет сообщения, что сайт недоступен, хотя все работает и даже из ЯндексВэбмастера можно получить ответ от сервера. Такое впечатление, что вы их адреса иногда избирательно за что-то блочите. Для примера статистика:
                          • 14 марта в 18:15 — стал недоступен; 14 марта в 21:21 — доступен снова.
                          • 12 марта в 08:13 — стал недоступен; 12 марта в 11:16 — доступен снова.
                          • 08 марта в 23:46 — стал недоступен; 11 марта в 06:39 — доступен снова.

                          Повторюсь, реально — сайт в это время работал. Есть только письма, что мониторинг ЯндексМетрики его не видит.
                          В моем случае не особо важно, ибо там визитка. Но мне кажется обидно, если вы иногда блочите поискового робота. Кажется за такое понижают в выдаче.
                            0
                            Какой-либо фильтрации по роботам не ведется. Какие-то уж очень большие интервалы времени получаются. А есть какая-то более детальная информация?
                              0
                              А какие детали нужны? Есть вот шесть писем от яндекс метрики: три — «сайт не работает» и три — «поздравляем, у вас все заработало».
                                0
                                Хотя бы отчет о причине проблемы. У них вроде есть такое — help.yandex.ru/metrika/reports/monitoring_results.xml (сам не пользуюсь метрикой поэтому может и не то).
                                  0
                                  За 8 и 12 марта написано Код ответа: No response received after 10 s и интервалы в течении которых сайт был недоступен, 2 дня 6:52:52 и 3:02:54 соответственно. За 14 марта Код ответа: ip address is unknown и интервал 3:06:18. На той-же странице обещают, что проверка проводится каждые 1 ч. 20 мин.
                                  Переносил к вам 8 марта. До этого была схема EC2 за cloudflare.com. На серверах cloudflare.com NS записи до сих пор указывают на их проксю (108.162.192.27 и 108.162.193.27). Возможно, что часть роботов Яндекса держали адреса в кэшах 6 днй, но cloudflare.com в этом случае всеравно бы отвечал данными из своего кэша.
                                    0
                                    Больше похоже на кэширование ДНС записей. Помимо я.метрики можно натравить селектеловский мониторинг на сайт.
                                      0
                                      Спасибо. На всякий случай спрошу у поддержки Яндекса. По большому счету данный конкретный случай меня сильно не беспокоит — важности в той визитке ноль.

                                      С другой стороны случай настораживает. Если это действительно кэширование ДНС, то так не должно быть, и нет гарантий что и поисковый робот не пользуется этими кэшами. Получается, что если слишком рано потушить старый сервер( раньше чем через неделю), можно получить понижение в выдаче за низкий аптайм ( сейчас метрика показывает 90%).
                                        0
                                        ДНС может кэшироваться на долгое время, это плата за его «живучесть».
                                          0
                                          Насколько я знаю, то нельзя кэшировать на время больше, чем предписывает TTL. Странно, что у Яндекса не ломается от такого кэширования Route53… там с TTL очень строго.
                            0
                            gzip включили уже?
                            0
                            Хотелось бы еще заметить, что привязка домена к контейнеру сделана немножко неудобно. В случае переезда сайт приляжет на время зависящее от ловкости осуществляющего переезд. Ибо сначала надо перенастроить все записи на фронтенд, и толко после того как они поднимутся интерфейс позволит привязать домен. Особенно в случае зоны ru ждать приходится долго и можно подзатянуть время в течении которого ДНС показывают на фронтенд который о сайте еще не знает.
                              0
                              Опять же, все операции с ДНС записями очень инертны. Админы которые выполняют какие-то переносы сайтов всегда должны держать это в голове.
                                0
                                Тут вопрос не в инертности, а в том, что небольшой даунтайм при переезде гарантирован алгоритмом привязки домена и избежать временной недоступности невозможно именно из-за требований чтобы А запись указывала на фронтенд, который еще не умеет отвечать на GET запрос по данному хосту.
                                  0
                                  Почему ж гарантирован? Никто не мешает перенести нужные данные в Хранилище, выполнить изменения в ДНС и привязку домена и при этом не отключать старый сервер. Все новые запросы будет обрабатывать Хранилище, а тем кому «не повезло» некоторое время будут на старом сервере. Дальше старый сервер отключаем (по прошествую TTL ДНС с запасом). Никакого даунтайма.
                                    +2
                                    Вы меня не поняли. Надо сначала настроить А запись DNS на IP хранилища. В это время у кого в кэшах стрый адрес — ходят по нему, а кто получает новый — получают ошибку, потому что хранилище еще не умеет обрабатывать этот домен. И только после того, как хранилище поймет, что А запись показывает на него, оно разрешает привязать домен. Ловкость нужна для того, чтобы поймать момент когда запись в корневых зонах обновилась и хранилище уже примет привязку. Поэтому и говорю, что алгоритм немного неудобный и даунтайм в любом случае гарантирован.
                                      +1
                                      При привязке домена записи проверяются на NS'ах самого домена, поэтому изменения видим быстро. Соглашусь, возможен некоторый провал, но если действовать оперативно, посетители сайта этого не заметят.

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

                            Самое читаемое