"Using OpenVZ to Create a Squid Proxy (http://beginlinux.com/server_training/proxy-server/1062-squi...)" - инструкция по изоляции прокси-сервера squid в контейнере OpenVZ.URL: http://beginlinux.com/server_training/proxy-server/1062-squi...
Новость: http://www.opennet.me/opennews/art.shtml?num=17751
А оно вообще надо?
Сквид и так работает с правами непривилегированного пользователя.То есть средствами pam_limits и quota
его можно ограничить, даже не имея VPS.Кроме того, у Сквида имеются собственные встроенные лимиты,
а уязвимости в нём находят гораздо реже,
чем в PHP, PHP-приложениях или Самбе.Впрочем, если я не прав - буду рад, если меня поправят :)
> А оно вообще надо?Там в статье, в самом-самом начале, автор даёт ответ на ваш вопрос:
> it provides better use of your hardware as you can set up other servers on the box.
> It also provides a very easy way to backup and create redundancy.Что в переводе на родной значит примерно следующее:
Это позволяет лучше использовать ваше железо, так как вы можете также поставить другие сервера на ту же машину. Это также даёт лёгкий способ делать резервные копии и создавать избыточность.
Мне кажется, лаконично и исчерпывающе. Если какие-то вопросы остались -- спрашивайте.
> Это позволяет лучше использовать ваше железо,
> так как вы можете также поставить другие сервера на ту же машину.То есть без VPS запустить на одной физической системе несколько сервисов уже невозможно?
> Это также даёт лёгкий способ делать резервные копии
Вообще-то для Сквида резервная копия должна содержать только /etc/squid*
И неважно, где при этом расположен Сквид - в VPS или нет.> и создавать избыточность.
Это что имеется в виду? Два Сквида на одном сервере?
>> Это позволяет лучше использовать ваше железо,
>> так как вы можете также поставить другие сервера на ту же машину.
>
>То есть без VPS запустить на одной физической системе несколько сервисов уже
>невозможно?Можно, конечно, просто с контейнерами удобнее -- они просто дают несколько новых степеней свободы, при этом вы вроде бы ничего не лишаетесь. В каждом контейнере отдельный сервис -- это удобно по ряду причин. Если очень кратко, то плюсы следующие:
1. Дополнительные механизмы контроля за ресурсами. Можно добавлять/отнимать память, дисковое пространство, процессор, всё это для каждого отдельного контейнера и довольно простым способом. В Линуксе практически нет возможностей контролировать *группы* процессов -- в OpenVZ есть. А ведь даже Апач -- это группа процессов.
2. Возможность иметь разные дистрибутивы Linux в разных контейнерах. Вот, например, Ораклу не всё равно (увы), на каком дистрибутиве работать -- вы можете специально для него организовать контейнер с RHEL5, а для сквида использовать ваш любимый и родной (к примеру) Debian Sarge.
3. Возможность менять компоненты системы внутри каждого контейнера отдельно. Вот, скажем, вы выяснили, что один из ваших демонов ну очень нуждается в функции ppoll(), которая появилась в glibc-2.4, а у вас стоит 2.3. Тут бы оную glibc и проапгрейдить, однако, совсем непонятно, как это отразится на других программах. В случае "отдельный контейнер для каждого сервиса" такой проблемы не стоит, более того... (см. следующий пункт).
4. Возможность создавать клоны. Продолжая предыдущий пример с апгрейдом glibc -- в случае с контейнерами мы можем создать клон контейнера и сделать этот рискованный апгрейд в нём, посмотрев, как всё это будет. В случае, если апгрейд glibc был плохой идеей, мы удаляем клон и живём спокойно дальше.
5. Улучшенная безопасность. Классический пример -- у вас на сервере стоит sendmail и named, в сендмейле дыра, хакер залезает и портит ваши DNS зоны. Разносим разные сервисы в разные контейнеры и радуемся, что такой сценарий становится крайне маловероятным. Я уже не говорю о том, что часто несколько "дыр" в разных софтинках используются совместно.
>> Это также даёт лёгкий способ делать резервные копии
>
>Вообще-то для Сквида резервная копия должна содержать только /etc/squid*
>И неважно, где при этом расположен Сквид - в VPS или нет.А что, конфиги сквида к версии никак не привязаны? Ох как привязаны, я лично на это налетал. Ну да ладно...
Тут, скорее, идея в том, что в контейнере стоит некая готовая система, которая что-то делает. Мы эту систему можем целиком забекапить, а потом целиком восстановить, и она будет работать. Больше того, контейнер не зависит от конкретного железа -- то есть, конечно, он зависит от архитектуры, но вот детали типа "а какой у нас SCSI контроллер", или "а где сколько дисков и партиций и куда они примонтированы", или "а какой модуль нужен для сетевой карты, и какие к нему параметры" -- их в контейнере нет. Поэтому контейнер к железу не привязан, его можно бекапить с одного OpenVZ хоста, а ресторить на другом.
>> и создавать избыточность.
>
>Это что имеется в виду? Два Сквида на одном сервере?Под термином redundancy обычно имеют в виду повышение надёжности за счёт избыточности, дублирования и т.п. Может быть, автор имел в виду то, что бекапы можно ресторить на другую машину и там запускать сквид.