Version v14.3 (2013-01-25 00:28) [AUTO]

s4a.tex

@@ -14,7 +14,7 @@
 \hypersetup{pdftitle={systemd для администраторов},%
 pdfauthor={Lennart Poettering, Sergey Ptashnick}}
 % Не засоряем оглавление подразделами
-\setcounter{tocdepth}{1}
+%\setcounter{tocdepth}{1} % А почему бы и нет?
 % Несколько сокращений
 \newcommand{\sectiona}[1]{\section*{#1}\addcontentsline{toc}{section}{#1}}
 \newcommand{\hreftt}[2]{\href{#1}{\texttt{#2}}}
@@ -3959,13 +3959,15 @@ CPUShares=1500
 дистрибутиве (если это включение не~указать явно, данный файл будет проигнорирован).
 Далее, мы указываем тот параметр, который хотим изменить. Сохраняем файл,
 приказываем systemd перечитать конфигурацию, и перезапускаем Apache, чтобы
-настройки вступили в силу\footnote{Прим. перев.: К сожалению, в настоящее время
-systemd не~поддерживает изменение параметров контрольных групп без перезапуска
-службы. Но вы можете узнать контрольную группу службы командой наподобие
-+systemctl show -p ControlGroup avahi-daemon.service+, и выполнить настройки
-любым удобным для вас способом, например, через запись значений в псевдофайлы
-cgroupfs. Разумеется, при следующем запуске службы к ней будут применены
-параметры, указанные в конфигурационном файле.}:
+настройки вступили в силу\footnote{Прим. перев.: systemd версий до 197
+включительно, не~поддерживает изменение параметров контрольных групп без
+перезапуска службы. Но вы можете узнать контрольную группу службы командой
+наподобие +systemctl show -p ControlGroup avahi-daemon.service+, и выполнить
+настройки любым удобным для вас способом, например, через запись значений в
+псевдофайлы cgroupfs (разумеется, при следующем запуске службы к ней будут
+применены параметры, указанные в конфигурационном файле). Начиная с systemd 198,
+в программу +systemctl+ добавлена поддержка команд +set-cgroup-attr+,
++unset-cgroup-attr+ и +get-cgroup-attr+.}:
 \begin{Verbatim}
 systemctl daemon-reload
 systemctl restart httpd.service
@@ -4297,16 +4299,21 @@ $ gdbus call --system --dest org.freedesktop.systemd1 --object-path /org/freedes
 постоянно остается открытым для входящих соединений, и все они обрабатываются
 быстро и корректно.
 
-Такая конфигурация позволяет снизить потребление ресурсов: службы работают и
-потребляют ресурсы только тогда, когда это действительно необходимо. Многие
-интернет-сайты и службы могут использовать это с выгодой для себя. Например,
-хостеры веб-сайтов знают, что из огромного количества существующих в Интернете
-сайтов лишь малая часть получает непрерывный поток запросов. Большинство же
-сайтов, хотя и должны постоянно оставаться доступными, получают запросы очень
-редко. Используя сокет-активацию, вы можете воспользоваться этим: разместив
-множество таких сайтов на одной системе и активируя их службы только при
-необходимости, вы получаете возможность <<оверкоммита>>: ваша система
-будет обслуживать сайтов больше, чем формально позволяют ее ресурсы. Разумеется,
+Такая конфигурация позволяет снизить потребление системных ресурсов: службы
+работают и потребляют ресурсы только тогда, когда это действительно необходимо.
+Многие интернет-сайты и службы могут использовать это с выгодой для себя.
+Например, хостеры веб-сайтов знают, что из огромного количества существующих в
+Интернете сайтов лишь малая часть получает непрерывный поток запросов.
+Большинство же сайтов, хотя и должны постоянно оставаться доступными, получают
+запросы очень редко. Используя сокет-активацию, вы можете воспользоваться этим:
+разместив множество таких сайтов на одной системе и активируя их службы только
+при необходимости, вы получаете возможность <<оверкоммита>>: ваша система будет
+обслуживать сайтов больше, чем формально позволяют ее ресурсы\footnote{Прим.
+перев.: Стоит отметить, что подобная схема работает только при условии, что для
+каждого клиентского сайта запускаются отдельные процессы служб, хотя это и
+происходит в рамках одного хоста. Не~очень распространенный в отчественном
+хостинге вариант: обычно следующей опцией после shared-хостинга (одна служба на
+всех клиентов) идет VPS (каждому клиенту по виртуальному хосту).}. Разумеется,
 увлекаться оверкоммитом не~стоит, иначе в моменты пиковой нагрузки ресурсов
 может действительно не~хватить.
 
@@ -4319,14 +4326,19 @@ $ gdbus call --system --dest org.freedesktop.systemd1 --object-path /org/freedes
 \hyperref[sec:instances]{экземплярами служб} позволяет  подготовить
 универсальные шаблоны конфигурации служб, и в соответствии с ними для каждого
 сайта будет запускаться свой экземпляр службы. Кроме того, не~стоит забывать,
-что systemd предоставляет \hyperref[sec:security]{богатый арсенал}
+что systemd предоставляет \hyperref[sec:security]{внушительный арсенал}
 механизмов обеспечения безопасности и разграничения доступа, который позволит
 изолировать клиентские сайты друг от друга (например, службы каждого клиента
 будут видеть только его собственный домашний каталог, в то время как каталоги
 всех остальных пользователей будут им недоступны). Итак, в конечном итоге вы
 получаете надежную и масштабируемую серверную систему, на сравнительно небольших
 ресурсах которой функционирует множество безопасно изолированных друг от друга
-служб~--- и все это реализовано штатными возможностями вашей ОС.
+служб~--- и все это реализовано штатными возможностями вашей ОС\footnote{Прим.
+перев.: В качестве практического примера использования сокет-активации служб
+systemd в промышленных серверных платформах, можно предложить
+\href{http://savanne.be/articles/deploying-node-js-with-systemd/}{вот эту
+статью}, наглядно описывающую применение этой и других технологий (мониторинг,
+использование Journal, ограничение ресурсов и доступа) на примере Node.js.}.
 
 Подобные конфигурации уже используются на рабочих серверах ряда компаний. В
 частности, специалисты из \href{https://www.getpantheon.com/}{Pantheon}
@@ -4368,12 +4380,12 @@ systemd 197 (и, соответственно, с Fedora~19), мы добави
 в systemd простейшим контейнерным менеджером~---
 \hyperref[sec:chroots]{systemd-nspawn}. Мы надеемся, что соответствующая
 возможность вскоре появится и в
-\href{http://libvirt.org/drvlxc.html}{libvirt-lxc}. А пока рассмотрим
-использование этого механизма на примере systemd-nspawn.
+\href{http://libvirt.org/drvlxc.html}{libvirt-lxc}. А пока, за отсутствие
+альтернатив, рассмотрим использование этого механизма на примере systemd-nspawn.
 
 Начнем с установки файлов ОС контейнера в выбранный каталог. Детальное
 рассмотрение этого вопроса выходит далеко за рамки нашего обсуждения, и
-при этом детально рассмотрено во многих статьях и руководствах. Поэтому
+при том детально рассмотрено во многих статьях и руководствах. Поэтому
 ограничусь лишь несколькими наиболее важными замечаниями. В частности, команда
 для установки Fedora будет выглядеть следующим образом:
 \begin{Verbatim}
@@ -4399,7 +4411,7 @@ $ debootstrap --arch=amd64 unstable /srv/mycontainer/
 
 Итак, ваш контейнер нормально загружается и работает. Подготовим для него
 service-файл, при помощи которого systemd сможет запускать и останавливать
-виртуальное окружение. Для этого, создадим на хост системе файл
+виртуальное окружение. Для этого, создадим на хост-системе файл
 +/etc/systemd/system/mycontainer.service+ со следующим содержанием:
 \begin{Verbatim}
 [Unit]
@@ -4417,10 +4429,10 @@ KillMode=process
 корневой каталог у них один и тот же, пространства имен (например, списки
 процессов) у каждого будут свои. Впрочем, данная задача может быть решена
 утилитой +nsenter+, которая должна войти в следующий релиз util-linux
-(предположительно, 2.23).}.  Настроим на контейнере SSH-сервер, причем таким
-образом, что подключение к его порту активировало весь контейнер, а затем
-активировало сервер, работающий внутри. Начнем с того, что прикажем хосту
-слушать порт SSH для контейнера. Для этого создадим на хосте файл
+(предположительно, 2.23).}. Чтобы исправить это упущение, настроим на контейнере
+SSH-сервер, причем таким образом, что подключение к его порту активировало весь
+контейнер, а затем активировало сервер, работающий внутри. Начнем с того, что
+прикажем хосту слушать порт SSH для контейнера. Для этого создадим на хосте файл
 +/etc/systemd/system/mycontainer.socket+:
 \begin{Verbatim}
 [Unit]
@@ -4441,13 +4453,14 @@ ListenStream=23
 nspawn. Впрочем, опытные администраторы легко могут найти обходные пути,
 например: присваивание хосту дополнительного IP-адреса (безо всякой
 виртуализации, командой +ip addr add+) и привязка слушающих сокетов к конкретным
-адресам (в параметре +ListenStream=+ сокет-файлов или в директиве
-+ListenAddress+ файла +sshd_config+).}. 
+адресам (в параметре +ListenStream=+ сокет-файлов и/или в директиве
++ListenAddress+ файла +sshd_config+ хоста).}. 
 
 Пока что systemd, работающий внутри контейнера, не~знает, что делать с тем
 сокетами, которые ему передает systemd хоста. Если вы попробуете подключиться к
 порту 23, контейнер запустится, но сетевое соединение немедленно будет закрыто,
-так как этому сокету не~соответствует пока никакой сервер. Давайте это исправим!
+так как данному сокету не~соответствует пока никакой сервер. Давайте это
+исправим!
 
 Настройка сокет-активации службы SSH была детально рассмотрена 
 \hyperref[sec:inetd]{в одной из предыдущих статей}, поэтому ограничусь
@@ -4503,15 +4516,24 @@ systemd начнет прослушивать TCP-порт 23. При подкл
 соединения экземпляр +sshd@.service+, что позволит нам залогиниться в контейнер
 по SSH.
 
-Если нам нужно запуститьунтри контейнера другие службы с сокет-активацией, мы 
+Если нам нужно запуститьунтри контейнера другие службы с сокет-активацией, мы
 можем добавить в +mycontainer.socket+ дополнительные сокеты. Все они будут
 прослушиваться, обращение к любому из них приведет к активации контейнера, и все
-они будут переданы контейнеру при его активации. Внутри контейнера они будут
-обработаны соответствии с настройками имеющихся там сокет-юнитов. Те сокеты, для
-которых соответствующих юнитов не~найдется, будут закрыты, а те сокеты, которые
-будут настроены для прослушивания внутри контейнера, но не~получены от хоста,
-будут активированы и доступны изнутри контейнера (а если это сетевые или
-файловые unix-сокеты, то и извне).
+эти сокеты будут переданы контейнеру при его активации. Внутри контейнера они
+будут обработаны соответствии с настройками имеющихся там сокет-юнитов. Те
+сокеты, для которых соответствующих юнитов не~найдется, будут
+закрыты\footnote{Прим. перев.: Стоит особо отметить, что описанная технология
+работает только для служб, поддерживающих сокет-активацию в режимах inetd (все
+классические inetd-службы, кроме встроенных) или systemd (зависят от библиотеки
++libsystemd-daemon.so+, либо содержат в исходниках заголовочный файл
++sd-daemon.h+). Службы, которые сами открывают себе слушающий сокет и
+не~содержат кода для приема уже открытого сокета, так активировать нельзя.
+Точнее, в случае с сетевыми и файловыми сокетами, все-таки можно, но первое
+соединение/сообщение при этом будет <<потрачено>> на запуск контейнера, и до
+службы в итоге дойдут только последующие, начина со второго, что сводит выгоды
+практически к нулю.}, а те сокеты, которые будут настроены для прослушивания
+внутри контейнера, но не~получены от хоста, будут активированы и доступны
+изнутри контейнера (а если это сетевые или файловые unix-сокеты, то и извне).
 
 Итак, давайте отступим чуть назад и полюбуемся на результаты наших трудов. Что
 мы получили в итоге? Возможность настраивать на одном хосте множество
@@ -4539,6 +4561,24 @@ libvirt-lxc или nspawn, но не~c qemu/kvm или xen.
 \href{http://www.freedesktop.org/software/systemd/man/journalctl.html}{journalctl(1)}.}.
 Ловко, не~правда ли?
 
+Необходимый минимум технологий для сокет-активации контейнеров, присутствует в
+systemd, начиная с версии 197. Тем не~менее, наша работа в этой области еще
+не~закончена, и в ближайшее время мы планируем доработать некоторые моменты.
+Например, сейчас, даже если все серверные службы внутри контейнера
+закончили обработку запросов и завершились, контейнер все равно продолжает
+функционировать и потреблять ресурсы хоста. Мы просто обязаны реализовать
+возможность автоматического завершения работы гостевой системы в такой ситуации.
+Причем у нас уже есть готовые наработки в этой области~--- мы можем
+задействовать уже существующую инфраструктуру, обеспечивающую автоматическое
+засыпание/выключение ноутбука при отсутствии активных задач и пользователей.
+
+Впрочем, пора закругляться, а то статья получается чересчур длинной. Надеюсь,
+что вы смогли продраться через все эти длинные и скучные рассуждения о
+виртуализации, сокетах, службах, различных ОС и прочем колдунстве. Также
+надеюсь, что эта статья станет хорошей отправной точкой при конфигурировании
+мощных и хорошо масштабируемых серверных систем. За дополнительной информацией
+обращайтесь к документации или приходите на наш IRC-канал. Спасибо за внимание!
+
 \end{document}
 
 vim:ft=tex:tw=80:spell:spelllang=ru