Comments 46
Хабр не для копипаста
К вам на сервер можно заливать автоматически? По API или еще как то?
Работать с облачным хранилищем можно при помощи браузера (через панель управления услугами Селектел), любого FTP-клиента или OpenStack Swift-совместимого программного обеспечения. Количество подходящего для работы с облачным хранилищем ПО насчитывает десятки приложений под любые операционные системы. Специально для iPhone нами было создано мобильное приложение Cloud Storage (доступно в App Store).
storage.selectel.ru/vozmozhnosti/sposobi-dostupa/
Конечно можно. Через общераспространенное API swift, частично s3 и еще через некоторые наши плюшки :-)
Хочу как диск подмонтировать в вин/линуксе (как блочное хранилище желательно) — есть простые решения?
Хранилище является объектным, напрямую работать «блочный» способом нельзя, но есть ряд программ которые эмулируют блочную работу, только у них есть свои недостатки и ограничения. Например, s3ql.
дык ncftp / scp не?
Туда бы еще SSI (разумеется, no-exec) :)
А что полезного можно реализовать на SSI?
Я как-то пробовал сайт-визитку делать, так задолбался и переехал на phtml.
Я как-то пробовал сайт-визитку делать, так задолбался и переехал на phtml.
Полезного, ну например вынести меню, шапку, футер в отдельный файл.
Вы просто готовить не умеете :)
Пример: скажем, готовите вы сайт текстового нединамического свойства, скажем, с документацией на Apache. Вы вынесли header и footer в отдельные файлы, отрендерили содержимое сайта в виде html страниц, указали в каждой в начале и конце теги включения header-а и footer-а — вот вам и страницы с оформением, притом не пришлось в каждую из страничек добавлять содержимое header-а и footer-а.
А самое приятное — DDoS этот сайт, случись нужда, переживет легко, и по цене отдачи трафика, что будет даже и недорого. Процессор оплачивать не придется :)
Рендерить будете скриптом на локальной машине, и им же, через API Selectel-а, зальете странички в облако.
Пример: скажем, готовите вы сайт текстового нединамического свойства, скажем, с документацией на Apache. Вы вынесли header и footer в отдельные файлы, отрендерили содержимое сайта в виде html страниц, указали в каждой в начале и конце теги включения header-а и footer-а — вот вам и страницы с оформением, притом не пришлось в каждую из страничек добавлять содержимое header-а и footer-а.
А самое приятное — DDoS этот сайт, случись нужда, переживет легко, и по цене отдачи трафика, что будет даже и недорого. Процессор оплачивать не придется :)
Рендерить будете скриптом на локальной машине, и им же, через API Selectel-а, зальете странички в облако.
В копилку статикогенераторов:
thewml.org/
уже сто лет как начал пользоваться (это, наверное, родоначальник, раньше всех других появился) — простой, при необходимости — хорошо расширяемый, ну и довольно удобно.
thewml.org/
уже сто лет как начал пользоваться (это, наверное, родоначальник, раньше всех других появился) — простой, при необходимости — хорошо расширяемый, ну и довольно удобно.
А что по ширине каналов?
SSI поддерживается?
получает на счет 10 рублей. Этой суммы вполне достаточно для того, чтобы хранить 1 Гб данных (и скачать 1 Гб данных) в течение 1 месяца.
А на storage.selectel.ru/stoimost/:
Например, этого хватит_чтобы 3 месяца хранить 1 Гб данных и скачать 1 Гб данных.
Немного оффтоп, но я бы еще добавил в список популярных статикогенераторов Harp.js
Достаточно новый, но быстро развивающийся проект. Может кому пригодится.
Достаточно новый, но быстро развивающийся проект. Может кому пригодится.
Вообще, здорово что вы разрешаете привязать домен второго уровня к хранилищу. У амазона, чтобы так сделать c S3, надо начать платить за их Rote53. Можно конечно схитрить с wwwizer.com, но ваше решение красивше.
Единственный вопрос: вы не дружите с яндексом? Периодически метрика шлет сообщения, что сайт недоступен, хотя все работает и даже из ЯндексВэбмастера можно получить ответ от сервера. Такое впечатление, что вы их адреса иногда избирательно за что-то блочите. Для примера статистика:
Повторюсь, реально — сайт в это время работал. Есть только письма, что мониторинг ЯндексМетрики его не видит.
В моем случае не особо важно, ибо там визитка. Но мне кажется обидно, если вы иногда блочите поискового робота. Кажется за такое понижают в выдаче.
Единственный вопрос: вы не дружите с яндексом? Периодически метрика шлет сообщения, что сайт недоступен, хотя все работает и даже из ЯндексВэбмастера можно получить ответ от сервера. Такое впечатление, что вы их адреса иногда избирательно за что-то блочите. Для примера статистика:
- 14 марта в 18:15 — стал недоступен; 14 марта в 21:21 — доступен снова.
- 12 марта в 08:13 — стал недоступен; 12 марта в 11:16 — доступен снова.
- 08 марта в 23:46 — стал недоступен; 11 марта в 06:39 — доступен снова.
Повторюсь, реально — сайт в это время работал. Есть только письма, что мониторинг ЯндексМетрики его не видит.
В моем случае не особо важно, ибо там визитка. Но мне кажется обидно, если вы иногда блочите поискового робота. Кажется за такое понижают в выдаче.
Какой-либо фильтрации по роботам не ведется. Какие-то уж очень большие интервалы времени получаются. А есть какая-то более детальная информация?
А какие детали нужны? Есть вот шесть писем от яндекс метрики: три — «сайт не работает» и три — «поздравляем, у вас все заработало».
Хотя бы отчет о причине проблемы. У них вроде есть такое — help.yandex.ru/metrika/reports/monitoring_results.xml (сам не пользуюсь метрикой поэтому может и не то).
За 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 в этом случае всеравно бы отвечал данными из своего кэша.
Переносил к вам 8 марта. До этого была схема EC2 за cloudflare.com. На серверах cloudflare.com NS записи до сих пор указывают на их проксю (108.162.192.27 и 108.162.193.27). Возможно, что часть роботов Яндекса держали адреса в кэшах 6 днй, но cloudflare.com в этом случае всеравно бы отвечал данными из своего кэша.
Больше похоже на кэширование ДНС записей. Помимо я.метрики можно натравить селектеловский мониторинг на сайт.
Спасибо. На всякий случай спрошу у поддержки Яндекса. По большому счету данный конкретный случай меня сильно не беспокоит — важности в той визитке ноль.
С другой стороны случай настораживает. Если это действительно кэширование ДНС, то так не должно быть, и нет гарантий что и поисковый робот не пользуется этими кэшами. Получается, что если слишком рано потушить старый сервер( раньше чем через неделю), можно получить понижение в выдаче за низкий аптайм ( сейчас метрика показывает 90%).
С другой стороны случай настораживает. Если это действительно кэширование ДНС, то так не должно быть, и нет гарантий что и поисковый робот не пользуется этими кэшами. Получается, что если слишком рано потушить старый сервер( раньше чем через неделю), можно получить понижение в выдаче за низкий аптайм ( сейчас метрика показывает 90%).
gzip включили уже?
Нет, gzip никто не обещал.
habrahabr.ru/company/selectel/blog/165807/#comment_5725077
Можно уже не следить? :-)
Enchant,15 января 2013 в 17:22
Эта возможность рассматривается, следите за обновлениями :-)
Можно уже не следить? :-)
Хотелось бы еще заметить, что привязка домена к контейнеру сделана немножко неудобно. В случае переезда сайт приляжет на время зависящее от ловкости осуществляющего переезд. Ибо сначала надо перенастроить все записи на фронтенд, и толко после того как они поднимутся интерфейс позволит привязать домен. Особенно в случае зоны ru ждать приходится долго и можно подзатянуть время в течении которого ДНС показывают на фронтенд который о сайте еще не знает.
Опять же, все операции с ДНС записями очень инертны. Админы которые выполняют какие-то переносы сайтов всегда должны держать это в голове.
Тут вопрос не в инертности, а в том, что небольшой даунтайм при переезде гарантирован алгоритмом привязки домена и избежать временной недоступности невозможно именно из-за требований чтобы А запись указывала на фронтенд, который еще не умеет отвечать на GET запрос по данному хосту.
Почему ж гарантирован? Никто не мешает перенести нужные данные в Хранилище, выполнить изменения в ДНС и привязку домена и при этом не отключать старый сервер. Все новые запросы будет обрабатывать Хранилище, а тем кому «не повезло» некоторое время будут на старом сервере. Дальше старый сервер отключаем (по прошествую TTL ДНС с запасом). Никакого даунтайма.
Вы меня не поняли. Надо сначала настроить А запись DNS на IP хранилища. В это время у кого в кэшах стрый адрес — ходят по нему, а кто получает новый — получают ошибку, потому что хранилище еще не умеет обрабатывать этот домен. И только после того, как хранилище поймет, что А запись показывает на него, оно разрешает привязать домен. Ловкость нужна для того, чтобы поймать момент когда запись в корневых зонах обновилась и хранилище уже примет привязку. Поэтому и говорю, что алгоритм немного неудобный и даунтайм в любом случае гарантирован.
Sign up to leave a comment.
Статические сайты в облачном хранилище