Mercurial > hg > nginx-site
annotate xml/ru/docs/beginners_guide.xml @ 1870:fa7542e40381
Relocated $ssl_client_i_dn, $ssl_client_i_dn_legacy, $ssl_client_serial.
author | Yaroslav Zhuravlev <yar@nginx.com> |
---|---|
date | Tue, 20 Dec 2016 17:46:00 +0300 |
parents | d43407143fa6 |
children |
rev | line source |
---|---|
936 | 1 <!-- |
2 Copyright (C) Nginx, Inc. | |
3 --> | |
4 | |
5 <!DOCTYPE article SYSTEM "../../../dtd/article.dtd"> | |
6 | |
7 <article name="Руководство для начинающих" | |
8 link="/ru/docs/beginners_guide.html" | |
9 lang="ru" | |
10 rev="1"> | |
11 | |
12 <section> | |
13 | |
14 <para> | |
15 В этом руководстве даётся начальное введение в nginx и описываются | |
16 некоторые простые задачи, которые могут быть решены с его помощью. | |
17 Предполагается, что nginx уже установлен на компьютере читателя. | |
18 Если нет, см. <link doc="install.xml"/>. | |
19 В этом руководстве описывается, как запустить и остановить nginx | |
20 и перезагрузить его конфигурацию, | |
21 объясняется, как устроен конфигурационный файл, и описывается, | |
22 как настроить nginx для раздачи статического содержимого, как | |
23 настроить прокси-сервер на nginx, и как связать nginx с приложением | |
24 FastCGI. | |
25 </para> | |
26 | |
27 <para> | |
28 У nginx есть один главный и несколько рабочих процессов. | |
29 Основная задача главного процесса — чтение и проверка конфигурации | |
30 и управление рабочими процессами. | |
31 Рабочие процессы выполняют фактическую обработку запросов. | |
32 nginx использует | |
33 модель, основанную на событиях, и зависящие от операционной системы | |
34 механизмы для эффективного распределения запросов между рабочими процессами. | |
35 Количество рабочих процессов задаётся в конфигурационном файле и | |
36 может быть фиксированным для данной конфигурации или автоматически | |
37 устанавливаться равным числу доступных процессорных ядер (см. | |
38 <link doc="ngx_core_module.xml" id="worker_processes"/>). | |
39 </para> | |
40 | |
41 <para> | |
42 Как работают nginx и его модули, определяется в конфигурационном файле. | |
43 По умолчанию, конфигурационный файл называется <path>nginx.conf</path> | |
44 и расположен в каталоге | |
45 <path>/usr/local/nginx/conf</path>, | |
46 <path>/etc/nginx</path> или | |
47 <path>/usr/local/etc/nginx</path>. | |
48 </para> | |
49 | |
50 </section> | |
51 | |
52 | |
53 <section id="control" name="Запуск, остановка, перезагрузка конфигурации"> | |
54 | |
55 <para> | |
56 Чтобы запустить nginx, нужно выполнить исполняемый файл. | |
57 Когда nginx запущен, им можно управлять, вызывая исполняемый файл с | |
58 параметром <literal>-s</literal>. | |
59 Используйте следующий синтаксис: | |
60 <programlisting> | |
61 nginx -s <i>сигнал</i> | |
62 </programlisting> | |
1491 | 63 Где <i>сигнал</i> может быть одним из нижеследующих: |
936 | 64 <list type="bullet"> |
65 <listitem> | |
66 <literal>stop</literal>—быстрое завершение | |
67 </listitem> | |
68 <listitem> | |
69 <literal>quit</literal>—плавное завершение | |
70 </listitem> | |
71 <listitem> | |
72 <literal>reload</literal>—перезагрузка конфигурационного файла | |
73 </listitem> | |
74 <listitem> | |
75 <literal>reopen</literal>—переоткрытие лог-файлов | |
76 </listitem> | |
77 </list> | |
78 Например, чтобы остановить процессы nginx с ожиданием окончания | |
79 обслуживания текущих запросов рабочими процессами, можно выполнить | |
80 следующую команду: | |
81 <programlisting> | |
82 nginx -s quit | |
83 </programlisting> | |
84 <note>Команда должна быть выполнена под тем же | |
85 пользователем, под которым был запущен nginx.</note> | |
86 </para> | |
87 | |
88 <para> | |
89 Изменения, сделанные в конфигурационном файле, | |
90 не будут применены, пока команда перезагрузить конфигурацию не будет | |
91 вручную отправлена nginx’у или он не будет перезапущен. | |
92 Для перезагрузки конфигурации выполните: | |
93 <programlisting> | |
94 nginx -s reload | |
95 </programlisting> | |
96 </para> | |
97 | |
98 <para> | |
99 Получив сигнал, главный процесс проверяет правильность синтаксиса нового | |
100 конфигурационного файла и пытается применить конфигурацию, содержащуюся | |
101 в нём. | |
102 Если это ему удаётся, главный процесс запускает новые рабочие процессы | |
103 и отправляет сообщения старым рабочим процессам с требованием завершиться. | |
104 В противном случае, главный процесс откатывает изменения и продолжает | |
105 работать со старой конфигурацией. | |
106 Старые рабочие процессы, получив команду завершиться, | |
107 прекращают принимать новые запросы и продолжают обслуживать текущие запросы | |
108 до тех пор, пока все такие запросы не будут обслужены. | |
1419
33e5af4c10d9
Typo fixed in the beginners guide.
Yaroslav Zhuravlev <yar@nginx.com>
parents:
1249
diff
changeset
|
109 После этого старые рабочие процессы завершаются. |
936 | 110 </para> |
111 | |
112 <para> | |
113 Посылать сигналы процессам nginx можно также средствами Unix, | |
114 такими как утилита <command>kill</command>. | |
115 В этом случае сигнал отправляется напрямую процессу с данным ID. | |
116 ID главного процесса nginx записывается по умолчанию в файл | |
117 <path>nginx.pid</path> в каталоге | |
118 <path>/usr/local/nginx/logs</path> или | |
119 <path>/var/run</path>. | |
120 Например, если ID главного процесса равен 1628, для отправки сигнала QUIT, | |
121 который приведёт к плавному завершению nginx, нужно выполнить: | |
122 <programlisting> | |
123 kill -s QUIT 1628 | |
124 </programlisting> | |
125 Для просмотра списка всех запущенных процессов nginx может быть использована | |
126 утилита <command>ps</command>, например, следующим образом: | |
127 <programlisting> | |
128 ps -ax | grep nginx | |
129 </programlisting> | |
130 Дополнительную информацию об отправке сигналов процессам nginx | |
131 можно найти в <link doc="control.xml"/>. | |
132 </para> | |
133 | |
134 </section> | |
135 | |
136 | |
137 <section id="conf_structure" name="Структура конфигурационного файла"> | |
138 | |
139 <para> | |
140 nginx состоит из модулей, которые настраиваются директивами, указанными | |
141 в конфигурационном файле. | |
142 Директивы делятся на простые и блочные. | |
143 Простая директива состоит из имени и параметров, разделённых пробелами, | |
144 и оканчивается точкой с запятой (<literal>;</literal>). | |
145 Блочная директива устроена так же, как и простая директива, но | |
146 вместо точки с запятой после имени и параметров следует набор дополнительных | |
147 инструкций, помещённых внутри фигурных скобок | |
148 (<literal>{</literal> и <literal>}</literal>). | |
149 Если у блочной директивы внутри фигурных скобок можно задавать другие | |
150 директивы, то она называется контекстом (примеры: | |
151 <link doc="ngx_core_module.xml" id="events"/>, | |
152 <link doc="http/ngx_http_core_module.xml" id="http"/>, | |
153 <link doc="http/ngx_http_core_module.xml" id="server"/> | |
154 и | |
155 <link doc="http/ngx_http_core_module.xml" id="location"/>). | |
156 </para> | |
157 | |
158 <para> | |
159 Директивы, помещённые в конфигурационном файле вне любого контекста, | |
160 считаются находящимися в контексте | |
161 <link doc="ngx_core_module.xml">main</link>. | |
162 Директивы <literal>events</literal> и <literal>http</literal> | |
163 располагаются в контексте <literal>main</literal>, <literal>server</literal> — | |
164 в <literal>http</literal>, а <literal>location</literal> — в | |
165 <literal>server</literal>. | |
166 </para> | |
167 | |
168 <para> | |
169 Часть строки после символа <literal>#</literal> считается комментарием. | |
170 </para> | |
171 | |
172 </section> | |
173 | |
174 | |
175 <section id="static" name="Раздача статического содержимого"> | |
176 | |
177 <para> | |
178 Одна из важных задач конфигурации nginx — раздача | |
179 файлов, таких как изображения или статические HTML-страницы. | |
180 Рассмотрим пример, в котором в зависимости от запроса файлы будут | |
181 раздаваться из разных локальных каталогов: <path>/data/www</path>, | |
182 который содержит HTML-файлы, и <path>/data/images</path>, | |
183 содержащий файлы с изображениями. | |
184 Для этого потребуется отредактировать конфигурационный файл и настроить | |
185 блок | |
186 <link doc="http/ngx_http_core_module.xml" id="server"/> | |
187 внутри блока <link doc="http/ngx_http_core_module.xml" id="http"/> | |
188 с двумя блоками <link doc="http/ngx_http_core_module.xml" id="location"/>. | |
189 </para> | |
190 | |
191 <para> | |
192 Во-первых, создайте каталог <path>/data/www</path> и положите в него файл | |
193 <path>index.html</path> с любым текстовым содержанием, а также | |
194 создайте каталог <path>/data/images</path> и положите в него несколько | |
195 файлов с изображениями. | |
196 </para> | |
197 | |
198 <para> | |
199 Далее, откройте конфигурационный файл. | |
200 Конфигурационный файл по умолчанию уже включает в себя несколько | |
201 примеров блока <literal>server</literal>, большей частью закомментированных. | |
202 Для нашей текущей задачи лучше закомментировать все такие блоки и | |
203 добавить новый блок <literal>server</literal>: | |
204 <programlisting> | |
205 http { | |
206 server { | |
207 } | |
208 } | |
209 </programlisting> | |
210 В общем случае конфигурационный файл может содержать несколько блоков | |
211 <literal>server</literal>, | |
212 <link doc="http/request_processing.xml">различаемых</link> по портам, на | |
213 которых они | |
214 <link doc="http/ngx_http_core_module.xml" id="listen">слушают</link>, | |
215 и по | |
216 <link doc="http/server_names.xml">имени сервера</link>. | |
217 Определив, какой <literal>server</literal> будет обрабатывать запрос, | |
218 nginx сравнивает URI, указанный в заголовке запроса, с параметрами директив | |
219 <literal>location</literal>, определённых внутри блока | |
220 <literal>server</literal>. | |
221 </para> | |
222 | |
223 <para> | |
224 В блок <literal>server</literal> добавьте блок <literal>location</literal> | |
225 следующего вида: | |
226 <programlisting> | |
227 location / { | |
228 root /data/www; | |
229 } | |
230 </programlisting> | |
231 Этот блок <literal>location</literal> задаёт “<path>/</path>” | |
232 в качестве префикса, который сравнивается с URI из запроса. | |
233 Для подходящих запросов добавлением URI к пути, указанному в директиве | |
234 <link doc="http/ngx_http_core_module.xml" id="root"/>, | |
235 то есть, в данном случае, к <path>/data/www</path>, получается | |
236 путь к запрашиваемому файлу в локальной файловой системе. | |
237 Если есть совпадение с несколькими блоками <literal>location</literal>, | |
1249
6885d0926e7b
Beginners guide: latin letter "c" changed to cyrillic "c".
Yaroslav Zhuravlev <yar@nginx.com>
parents:
936
diff
changeset
|
238 nginx выбирает блок с самым длинным префиксом. |
936 | 239 В блоке <literal>location</literal> выше указан самый короткий префикс, |
240 длины один, | |
241 и поэтому этот блок будет использован, только если не будет совпадения | |
242 ни с одним из остальных блоков <literal>location</literal>. | |
243 </para> | |
244 | |
245 <para> | |
246 Далее, добавьте второй блок <literal>location</literal>: | |
247 <programlisting> | |
248 location /images/ { | |
249 root /data; | |
250 } | |
251 </programlisting> | |
252 Он будет давать совпадение с запросами, начинающимися с | |
253 <literal>/images/</literal> | |
254 (<literal>location /</literal> для них тоже подходит, но указанный там префикс | |
255 короче). | |
256 </para> | |
257 | |
258 <para> | |
259 Итоговая конфигурация блока <literal>server</literal> должна выглядеть | |
260 следующим образом: | |
261 <programlisting> | |
262 server { | |
263 location / { | |
264 root /data/www; | |
265 } | |
266 | |
267 location /images/ { | |
268 root /data; | |
269 } | |
270 } | |
271 </programlisting> | |
272 Это уже работающая конфигурация сервера, слушающего на стандартном порту 80 | |
273 и доступного на локальном компьютере по адресу | |
274 <literal>http://localhost/</literal>. | |
275 В ответ на запросы, URI которых начинаются с <literal>/images/</literal>, | |
276 сервер будет отправлять файлы из каталога <path>/data/images</path>. | |
277 Например, на запрос | |
278 <literal>http://localhost/images/example.png</literal> nginx отправит | |
279 в ответ файл <path>/data/images/example.png</path>. | |
280 Если же этот файл не существует, nginx отправит ответ, указывающий на | |
281 ошибку 404. | |
282 Запросы, URI которых не начинаются на <literal>/images/</literal>, будут | |
283 отображены на каталог <path>/data/www</path>. | |
284 Например, в результате запроса | |
285 <literal>http://localhost/some/example.html</literal> в ответ будет | |
286 отправлен файл <path>/data/www/some/example.html</path>. | |
287 </para> | |
288 | |
289 <para> | |
290 Чтобы применить новую конфигурацию, запустите nginx, если он ещё не запущен, | |
291 или отправьте сигнал <literal>reload</literal> главному процессу nginx, | |
292 выполнив: | |
293 <programlisting> | |
294 nginx -s reload | |
295 </programlisting> | |
296 </para> | |
297 | |
298 <para> | |
299 <note> | |
300 В случае если что-то работает не как ожидалось, можно попытаться выяснить | |
301 причину с помощью файлов <path>access.log</path> и <path>error.log</path> | |
302 из каталога | |
303 <path>/usr/local/nginx/logs</path> или | |
304 <path>/var/log/nginx</path>. | |
305 </note> | |
306 </para> | |
307 | |
308 </section> | |
309 | |
310 | |
311 <section id="proxy" name="Настройка простого прокси-сервера"> | |
312 | |
313 <para> | |
314 Одним из частых применений nginx является использование его в качестве | |
315 прокси-сервера, то есть сервера, который принимает запросы, перенаправляет их | |
316 на проксируемые сервера, получает ответы от них и отправляет их клиенту. | |
317 </para> | |
318 | |
319 <para> | |
320 Мы настроим базовый прокси-сервер, который будет обслуживать запросы | |
321 изображений из локального каталога и отправлять все остальные запросы на | |
322 проксируемый сервер. | |
323 В этом примере оба сервера будут работать в рамках одного | |
324 экземпляра nginx. | |
325 </para> | |
326 | |
327 <para> | |
328 Во-первых, создайте проксируемый сервер, добавив ещё один блок | |
329 <literal>server</literal> в конфигурационный файл nginx со следующим | |
330 содержимым: | |
331 <programlisting> | |
332 server { | |
333 listen 8080; | |
334 root /data/up1; | |
335 | |
336 location / { | |
337 } | |
338 } | |
339 </programlisting> | |
340 Это будет простой сервер, слушающий на порту 8080 | |
341 (ранее директива <literal>listen</literal> не указывалась, потому что | |
342 использовался стандартный порт 80) и отображающий все | |
343 запросы на каталог <path>/data/up1</path> в локальной файловой | |
344 системе. | |
345 Создайте этот каталог и положите в него файл <path>index.html</path>. | |
346 Обратите внимание, что директива <literal>root</literal> помещена в контекст | |
347 <literal>server</literal>. | |
348 Такая директива <literal>root</literal> будет использована, когда директива | |
349 <literal>location</literal>, выбранная для выполнения запроса, не содержит | |
350 собственной директивы <literal>root</literal>. | |
351 </para> | |
352 | |
353 <para> | |
354 Далее, используйте конфигурацию сервера из предыдущего раздела | |
355 и видоизмените её, превратив в конфигурацию прокси-сервера. | |
356 В первый блок <literal>location</literal> добавьте директиву | |
357 <link doc="http/ngx_http_proxy_module.xml" id="proxy_pass"/>, | |
358 указав протокол, имя и порт проксируемого сервера в качестве параметра | |
359 (в нашем случае это <literal>http://localhost:8080</literal>): | |
360 <programlisting> | |
361 server { | |
362 location / { | |
363 proxy_pass http://localhost:8080; | |
364 } | |
365 | |
366 location /images/ { | |
367 root /data; | |
368 } | |
369 } | |
370 </programlisting> | |
371 </para> | |
372 | |
373 <para> | |
374 Мы изменим второй блок | |
375 <literal>location</literal>, который на данный момент отображает запросы | |
376 с префиксом <literal>/images/</literal> на файлы из каталога | |
377 <path>/data/images</path> так, чтобы он подходил для запросов изображений | |
378 с типичными расширениями файлов. | |
379 Изменённый блок <literal>location</literal> выглядит следующим образом: | |
380 <programlisting> | |
381 location ~ \.(gif|jpg|png)$ { | |
382 root /data/images; | |
383 } | |
384 </programlisting> | |
385 Параметром является регулярное выражение, дающее совпадение со всеми | |
386 URI, оканчивающимися на <path>.gif</path>, <path>.jpg</path> или | |
387 <path>.png</path>. | |
388 Регулярному выражению должен предшествовать символ <literal>~</literal>. | |
389 Соответствующие запросы будут отображены на каталог <path>/data/images</path>. | |
390 </para> | |
391 | |
392 <para> | |
393 Когда nginx выбирает блок <literal>location</literal>, | |
394 который будет обслуживать запрос, то вначале он проверяет | |
395 директивы <link doc="http/ngx_http_core_module.xml" id="location"/>, | |
396 задающие префиксы, запоминая <literal>location</literal> с самым | |
397 длинным подходящим префиксом, а затем проверяет регулярные выражения. | |
398 Если есть совпадение с регулярным выражением, nginx выбирает соответствующий | |
399 <literal>location</literal>, в противном случае берётся запомненный ранее | |
400 <literal>location</literal>. | |
401 </para> | |
402 | |
403 <para> | |
404 Итоговая конфигурация прокси-сервера выглядит следующим образом: | |
405 <programlisting> | |
406 server { | |
407 location / { | |
408 proxy_pass http://localhost:8080/; | |
409 } | |
410 | |
411 location ~ \.(gif|jpg|png)$ { | |
412 root /data/images; | |
413 } | |
414 } | |
415 </programlisting> | |
416 Этот сервер будет фильтровать запросы, оканчивающиеся на | |
417 <path>.gif</path>, <path>.jpg</path> или <path>.png</path>, | |
418 и отображать их на каталог <path>/data/images</path> (добавлением URI к | |
419 параметру директивы <literal>root</literal>) и перенаправлять все остальные | |
420 запросы на проксируемый сервер, сконфигурированный выше. | |
421 </para> | |
422 | |
423 <para> | |
424 Чтобы применить новую конфигурацию, отправьте сигнал <literal>reload</literal> | |
425 nginx’у, как описывалось в предыдущих разделах. | |
426 </para> | |
427 | |
428 <para> | |
429 Существует <link doc="http/ngx_http_proxy_module.xml">множество</link> | |
430 других директив для дальнейшей настройки прокси-соединения. | |
431 </para> | |
432 | |
433 </section> | |
434 | |
435 | |
436 <section id="fastcgi" name="Настройка проксирования FastCGI"> | |
437 | |
438 <para> | |
439 nginx можно использовать для перенаправления запросов на FastCGI-серверы. | |
440 На них могут исполняться приложения, созданные с использованием | |
441 разнообразных фреймворков и языков программирования, например, PHP. | |
442 </para> | |
443 | |
444 <para> | |
445 Базовая конфигурация nginx для работы с проксируемым FastCGI-сервером | |
446 включает в себя использование директивы | |
447 <link doc="http/ngx_http_fastcgi_module.xml" id="fastcgi_pass"/> | |
448 вместо директивы <literal>proxy_pass</literal>, | |
449 и директив <link doc="http/ngx_http_fastcgi_module.xml" id="fastcgi_param"/> | |
450 для настройки параметров, передаваемых FastCGI-серверу. | |
451 Представьте, что FastCGI-сервер доступен по адресу | |
452 <literal>localhost:9000</literal>. | |
453 Взяв за основу конфигурацию прокси-сервера из предыдущего раздела, | |
454 замените директиву <literal>proxy_pass</literal> на директиву | |
455 <literal>fastcgi_pass</literal> и измените параметр на | |
456 <literal>localhost:9000</literal>. | |
457 В PHP параметр <literal>SCRIPT_FILENAME</literal> используется для | |
458 определения имени скрипта, а в параметре <literal>QUERY_STRING</literal> | |
459 передаются параметры запроса. | |
460 Получится следующая конфигурация: | |
461 <programlisting> | |
462 server { | |
463 location / { | |
464 fastcgi_pass localhost:9000; | |
465 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; | |
466 fastcgi_param QUERY_STRING $query_string; | |
467 } | |
468 | |
469 location ~ \.(gif|jpg|png)$ { | |
470 root /data/images; | |
471 } | |
472 } | |
473 </programlisting> | |
474 Таким образом будет настроен сервер, который будет перенаправлять | |
475 все запросы, кроме запросов статических изображений, на проксируемый | |
476 сервер, работающий по адресу <literal>localhost:9000</literal>, | |
477 по протоколу FastCGI. | |
478 </para> | |
479 | |
480 </section> | |
481 | |
482 </article> |