19:56 

Kakou ECTb
After silence that which comes nearest to expressing the inexpressible is music.
Кто может подсказать направления поиска статей и мануалов? Ну или советы дать в комментарии :)

Задача : На чистый vps с одной из unix систем поставил nginx, который сможет отдавать простую статику (картинки)

Цели :

- Выяснить какая ось лучше всего подходит под эту задачу
- Как с нуля поставить nginx и настроить его вместе с самой осью
- Каким-то образом программно заливать туда изображения для отдачи (ftp? - какие еще варианты есть лёгкие для вхождения)


Касался только win, линукс никогда не пользовал. (разработчик asp.net/C#).

Любые советы и мануалы приветствуются. А если найдётся человек с нужным опытом, который согласится уделить чуть времени и вкратце расскажет что как и чего - буду очень благодарен. Разжёвывать ничего не надо, только направления куда копать, конфиги и тд постараюсь настроить сам по мануалам.

Комментарии
2014-01-11 в 20:24 

alhames
alhames.ru
Я летом купил vps, поставил туда CentOS, т.к. был ранее с ней знаком, ну и настроил какой-никакой сервер nginx + php-fpm + mysql
Вот сохранял себе подборку ссылок на инфу, которой пользовался - alhames.diary.ru/p191067713.htm

А вообще установка nginx по идеи состоит из одной команды:
yum install nginx

для red hat, или
apt-get install nginx

для debian

Ну можно конечно добавить другие репозитории (что я, собственно, и сделал), или собрать сервер со своими настройками - вот только зачем заморачиваться настолько на первоначальном этапе?
Либо можно поставить что-то аля ISPmanager и его установщик сам докачает и сконфигурирует то что нужно - но это как правило платный софт, и я не нашел в нем необходимости, т.к. все можно делать и через консоль.

Касательно "программно заливать изображения" - на нашем image-сервере это делается через php =)

2014-01-11 в 20:29 

Скептичный циник
Миру - мир. А Вам - пломбир!
Ой, я аж дежа вю словил! (о.0)

2014-01-11 в 20:51 

Kakou ECTb
After silence that which comes nearest to expressing the inexpressible is music.
Касательно "программно заливать изображения" - на нашем image-сервере это делается через php =) Т.е. на самом image сервере поднят php и через скрипт как-то разливаются файлы? Какая-то более сложная логика там у вас есть?

Спасибо за ответ.

2014-01-11 в 21:09 

alhames
alhames.ru
Т.е. на самом image сервере поднят php и через скрипт как-то разливаются файлы?
Там много разной логики, в том числе уже устаревшей и требующей переработки)
Суть в том что картинки заливаются в определенную структуру, а когда nginx их запрашивает - то в случае нахождения нужного ресайза файл отдается напрямую, в противном случае запускается скрипт, который ресайзит изображение, накладывает ватермарку и т.д. - это все на php.

А касательно как именно заливаются сами картинки из вне - то пока что двумя способами - через iframe и через запрос изображения по http.
Я ж не знаю какие у вас там картинки и что требуется с ними делать. Расскажите - поделюсь идеями :)

2014-01-11 в 21:19 

Скептичный циник
Миру - мир. А Вам - пломбир!
О, видимо, неправильно понял вопрос про статику. Поделюсь и я логикой для увеличения вариантов (:

Например, такой кейс на запись:
1. Юзверь на сайте (?) заливает картинку
2. Приложение обрабатывает её в соответствии с нужной логикой (валидация, ресайз, usw)
3. Шлёт на статик сервер POST с параметрами, которые указывают куда это положить и под каким именем
4. Сервер со статикой принимает запрос с картинкой и пишет уже на диск куда нужно

А такой на чтение:
1. Юзвер открывает страницу
2. Динамик-сервер проверяет наличие в кэше и если есть, то отдаёт оттуда
3. Если в кэше нет или устарел, то шлёт GET на статик-сервер с инфой о том по какому пути и какой файл забрать
4. Динамик получает картинку и отдаёт её юзверю, на этом же этапе можно с ней провести какие-нибудь изменения

Для такой логики на статик-сервере не нужен интерпретатор вообще – всё это реализуется средствами nginx. Если хочется, то можно ловить запросы на статике с помощью скрипта на любом языке (пхп/питон/баш/перл/си/...), смотря какой больше знаком или какой быстрее будет работать (пхп/си).

2014-01-11 в 21:24 

alhames
alhames.ru
3. Шлёт на статик сервер POST с параметрами, которые указывают куда это положить и под каким именем
Примерно по такому принципу работает вконтакт - vk.com/dev/upload_files =)
Там правда из-за высокой нагруженности нужно предварительно узнать на какой из серверов загружать файл

2014-01-11 в 21:30 

Скептичный циник
Миру - мир. А Вам - пломбир!
alhames, о, это интересно, спасибо за ссылку! Занятно посмотреть как это делают "большие дяди" с компилируемым пыхом.
Свой велосипед строил из исходя из принципов "на статике не должно быть никакой динамики" и "статик и динамик сервера могут находиться как угодно далеко". А вот с кучей статиков и как их разделять ещё не сталкивался.

2014-01-11 в 21:35 

Скептичный циник
Миру - мир. А Вам - пломбир!
Кстати, вопрос:
> двумя способами - через iframe и через запрос изображения по http.
В чём разница для сервера?

2014-01-11 в 22:12 

alhames
alhames.ru
Скептичный циник, "большие дяди" хранят все файлы в одном, дописывая каждый новый залитый файл в конец )

В чём разница для сервера?
В первом случае на сайте открывается iframe с img-сервера и картинка загружается на него напрямую.
Вообще изначально iframe делался для того чтобы не перезагружать страницу (лет, эдак, 10 назад), но отлично подошел и тут )

Ну а во втором случае мы просто шлем скрипту адрес картинки и он сам ее скачивает (насколько я помню, через обычный file_get_contents) - дело в том что картинки не обязательно пользователь заливает - они могут выдираться из текста, браться с других сайтов и т.д.

2014-01-11 в 22:41 

Kakou ECTb
After silence that which comes nearest to expressing the inexpressible is music.
Скептичный циник, на запись кейс один в один как планируется сделать.


А вот на чтение планирую так :

У меня на фронт сервере хранятся все линки на картинки image сервера, я формирую страницу на фронте а все линки ведут на сервер с nginx. Вида image.myfront.com/1.jpeg например. Т.е задача nginx просто отдать картинку и... всё.

Апач же для этого поднимать не нужно? Сам nginx умеет отдавать какую нибудь статистику? Например сколько было запросов и на какие файлы?

Я подумал использовать отдельный nginx сервер для того чтобы не грузить основной на котором будут морда, вся бизнес логика и БД. Ну а так как win сервер во-первых дорогой, а во вторых просто для отдачи статики жирно использовать IIS.

Как-то так в общем.

2014-01-11 в 22:43 

Скептичный циник
Миру - мир. А Вам - пломбир!
> "большие дяди" хранят все файлы в одном, дописывая каждый новый залитый файл в конец
Типа Redis, Riak или каких-нибудь других "ключ-значение"?

> картинка загружается на него напрямую
Разве iframe работает не через http? (о.0) Это ж просто html-тег.

Если стучаться с клиента сразу на static.example.com (т.е., напрямую, если нет разделения по ip/ns), то для сервера не важно каким образом это было сделано (curl, ajax, iframe, usw) – для него это будет один фиг входящий GET. А уж как сервер это обработает – другое дело. Я бы на месте сервера не доверял никакой входящей инфе вне зависимости от того откуда она была получена (ну кроме сессий, возможно).

2014-01-11 в 22:50 

Kakou ECTb
After silence that which comes nearest to expressing the inexpressible is music.
И ещё - какой конфигурации впски хватит для начала. Оговорюсь, что храниться будут в основном гифки. Т.е. средний файл будет около 10 МБ.нагрузка скажем 10 запросов/сек. На что упор делать - память или проц

2014-01-11 в 22:51 

Скептичный циник
Миру - мир. А Вам - пломбир!
Kakou ECTb

> Апач же для этого поднимать не нужно?
Не-а, не нужно. Nginx это может сделать сам. Он такой же полноценный сервер (:

> Сам nginx умеет отдавать какую нибудь статистику? Например сколько было запросов и на какие файлы?
Сам по себе "из коробки" он пишет логи. Собирать статистику можно распарсив эти логи.
Чтобы не изобретать велосипед посмотри в сторону Pinba (нужен отдельный сервер) или глянь на nginx-sla (отдельного сервера не нужно).

> Я подумал использовать отдельный nginx сервер для того чтобы не грузить основной на котором будут морда, вся бизнес логика и БД.
Для этого его чаще всего и используют (: Подходящий инструмент.

2014-01-11 в 23:03 

Скептичный циник
Миру - мир. А Вам - пломбир!
> На что упор делать - память или проц
Так сразу и не скажешь, нужно профилировать приложение. Если там будет только статика, то я бы сделал упор на проц и в nginx несколько воркеров чтобы работали параллельно (если проц позволяет).

2014-01-11 в 23:49 

alhames
alhames.ru
Типа Redis, Riak или каких-нибудь других "ключ-значение"?
Боюсь я не в состоянии сравнивать, т.к. не имел опыта работы ни с тем ни с другим. Если интересно, вот видео где все это рассказывалось - vk.com/video48660_167095251

Разве iframe работает не через http? (о.0) Это ж просто html-тег.
В случае iframe скрипт перемещает картинку из временной в нужное место в пределах одного сервера - так что тут нет http, я это имел ввиду.
Ну а на сам сервер картинка загружается само собой обыкновенной html-формой.

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

2014-01-12 в 00:11 

Скептичный циник
Миру - мир. А Вам - пломбир!
> Если интересно, вот видео
Интересно, спасибо!

> скрипт перемещает картинку из временной в нужное место
Не очень понял – зачем перемещать? Разве нет оверхеда от операций с ФС?

> В случае iframe скрипт перемещает картинку
А как он узнаёт что нужно что-то сделать? Не по дополнительному http-запросу?

> Ну там ключик еще передается, всякие фильтры и т.д.
Гм, конкретно от сюрпризов через картинки защититься не так уж и сложно (в них вполне несложно зашить php-код и выполнить, на апаче точно, на nginx просто не пробовал):
1. Статик-сервер не должен брать на исполнение ни один файл, принципиально. Лучше вообще запретить chmod'ом поголовно всё или не ставить интерпретаторы на этот сервер.
2. При получении картинки из внешнего источника брать только графическую инфу и создавать новую картинку (лишние данные типа внедрённого кода не попадут в новый графический файл). Если это слишком дорого, то хотя бы использовать белые списки для mime и брать его только из getimagesize(), а не из метаинфы от клиента.
3. Резать расширение и писать заново после п.2 на основании mime.
4. Скрывать внутреннюю файловую структуру и переименовывать файлы перед записью на диск.

2014-01-12 в 00:48 

alhames
alhames.ru
Скептичный циник,
Не очень понял – зачем перемещать?
Мы не храним пути - они генерируются из id объекта, который на момент загрузки картинки еще не известен.

А как он узнаёт что нужно что-то сделать? Не по дополнительному http-запросу?
По нему, но он выполняется с сервера и пользователь никак его не видит.

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

Лучше вообще запретить chmod'ом поголовно всё или не ставить интерпретаторы на этот сервер.
А как ресайзить на лету тогда? У верстальщика каждую неделю может новый размер изображений быть - каждый раз вручную генерировать превью очень муторно..

использовать белые списки для mime и брать его только из getimagesize(), а не из метаинфы от клиента.
Тримить расширение и вручную после п.2 на основании mime.
Скрывать внутреннюю файловую структуру и переименовывать файлы перед записью на диск.
Ну так оно и есть - загружаются только jpg, png и gif, но даже не из-за безопасности, просто другие типы изображений не ресайзятся =)
Имя загружаемого файла вообще никак не используется.

2014-01-12 в 01:12 

Скептичный циник
Миру - мир. А Вам - пломбир!
> А как ресайзить на лету тогда?
Зачем? Можно ресайзить однажды при аплоаде изображения, а затем просто дёргать со статики уже готовые заранее нарезанные и не тратить ресурсы каждый раз.
Если вдруг было запрошено изображение, которое есть, но не тех размеров, то оригинал посылается на сервер с приложением, где режется как нужно, а затем что угодно: отправляется юзверю, складывается обратно на статик, помещается в кэш и т.д.
У нас, например, плюс к абзацу выше используется дополнительных подход: верстальщик может из своего интерфейса указать какие изображения (или какие папки с ними) нуждаются в копии с новыми размерами – тогда в фоне без особой нагрузки на сервер режется всё, что он указал со скоростью не выше 100 изображений в минуту (число подобрано эмпирически "шоп не тупило").

     

@web-программирование

главная