helo, Pengguna yang dihormati Habrakhabra. Ceramah saya adalah tentang cara menyediakan tanah untuk projek pembangunan web tempatan di bilik operasi sistem Ubuntu 16.04.1 LTS.

Dalam artikel ini saya ingin menghilangkan dan menjelaskan kesukaran yang mungkin berkaitan dengan pemasangan dan konfigurasi perisian yang diperlukan untuk pembangunan web moden, yang mungkin dihadapi oleh pembangun pemula dan bukan sahaja.

Teknologi yang akan digunakan dalam artikel: nginx, php-fpm.

Sebelum memulakan cerita, saya ingin ambil perhatian bahawa saya melakukan semua tindakan ini pada sistem "telanjang".
Saya akan bekerjasama dengan pengurus pakej kebolehan. Saya juga mengesyorkan untuk mengemas kini indeks pakej dan pakej itu sendiri sebelum memasang perisian. Dalam artikel ini kita akan melakukan langkah-langkah ini bersama-sama.

Pergi!

Memasang pengurus pakej kebolehan, indeks dan kemas kini pakej

Pasang:

Sudo apt install aptitude
Kami mengemas kini indeks.

Kemas kini bakat sudo
Kami mengemas kini pakej (arahan akan mengemas kini semua pakej yang terdapat versi baharu; jika pakej perlu dialih keluar, ia akan dilakukan).

Peningkatan penuh bakat Sudo

Pemasangan dan konfigurasi nginx(versi >= 1.10.0)

Kami pasang.

Sudo aptitude memasang nginx
Jom lancarkan.

Perkhidmatan sudo nginx mula
Kami menyemak versi untuk memastikan bahawa kami tidak memasang yang lama, iaitu, lebih rendah daripada 1.10.0.

Pemasangan dan pelancaran telah selesai, sekarang mari pergi ke direktori tempat nginx kami dipasang dan lihat strukturnya. Direktori nginx terletak di laluan ini:

Cd /etc/nginx/
Anda boleh melihat kandungan direktori dengan arahan ls; dengan bendera -la ia akan menjadi lebih mudah untuk melihat kandungan direktori (sebenarnya, arahan ini dengan bendera tertentu boleh diterangkan dengan lebih terperinci dan lebih tepat, tetapi kita mempunyai topik yang berbeza hari ini).

Ls-la
Kami berminat masa ini dua direktori yang anda lihat dalam tangkapan skrin. Ini ialah direktori tapak yang tersedia dan didayakan tapak.

Mari pergi ke direktori tapak yang tersedia dan mula mengkonfigurasi hos maya kami (tapak).

Cd /etc/nginx/sites-available
Sebelum kita mula membuat fail konfigurasi, mari kita periksa apa yang kita ada katalog ini. Dalam kes saya, direktori itu tidak kosong, ia sudah mengandungi fail konfigurasi, saya memadamnya supaya tidak mengelirukan anda.

Penyimpangan penting

Bila pemasangan nginx"dari awal", iaitu "dari awal", sejak anda menyahpasang nginx dengan arahan
sudo apt-get remove nginx atau sudo apt remove fail konfigurasi nginx kekal dan jika anda tiba-tiba tidak faham mengapa nginx tidak berfungsi dan ingin memasangnya semula (biasanya pemula menggunakan ini pengguna Linux), maka walaupun selepas pemasangan semula ia tidak akan berfungsi dengan betul, kerana fail konfigurasi lama (ia tidak dipadamkan selepas penyingkiran dengan arahan keluarkan) mengandungi tetapan yang salah, ia perlu dipadam atau dikonfigurasikan dengan betul, barulah nginx akan berfungsi.

Saya mengesyorkan memadam dengan arahan sudo apt-get purge nginx atau sudo apt purge nginx. Jika anda menggunakan pengurus pakej kebolehan, kemudian arahan sudo aptitude purge nginx mengalih keluar keseluruhan pakej dengan semua kebergantungan dan fail konfigurasi.

Akan ada satu fail dalam direktori ini secara lalai, dipanggil lalai. Ia akan mengandungi fail konfigurasi dengan contoh, dengan ulasan, anda boleh mempelajarinya pada masa lapang anda, atau anda boleh memadamkannya sepenuhnya (anda sentiasa boleh menghubungi dokumentasi rasmi).

Ls-la

Mari buat fail konfigurasi kita sendiri, yang sepadan dengan nama domain tapak tempatan kami (atau yang sebenar, jika anda sudah tahu namanya). Ini mudah, pada masa hadapan, apabila terdapat banyak fail konfigurasi, ia akan menyelamatkan anda daripada kekeliruan di dalamnya. Bagi saya fail ini akan dipanggil project.local.

Projek sentuh sudo.local
Mari kita lihat apa yang berlaku.

Sekarang mari kita buka dalam editor, saya akan membukanya dalam nano.

Projek nano sudo.local
Kami melihat bahawa ia kosong. Sekarang mari kita teruskan untuk mencipta fail kami. Anda perlu membawa konfigurasi ke borang seperti yang ditulis di bawah. Saya akan menerangkan hanya arahan penting fail ini, saya tidak akan menerangkan yang lain, kerana ini tidak penting pada masa ini, selepas semua, kita mempunyai topik tetapan asas. Tetapan "slaid" ini cukup untuk membangunkan projek secara tempatan, bukan sahaja yang kecil, tetapi juga yang agak besar. Dalam artikel berikut saya akan menerangkan secara berasingan setiap arahan yang digunakan (itulah yang dipanggil baris, contohnya nama_server) bagi fail ini.

Lihat komen terus di fail konfigurasi.

Pelayan ( dengar 80; # port mendengar nginx server_name project.local; # Nama domain berkaitan dengan arus hos maya root /home/stavanger/code/project.local; # direktori di mana projek itu terletak, laluan ke indeks titik masuk index.php; # add_header Access-Control-Allow-Origin *; # layan fail statik terus lokasi ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ ( access_log off; tamat tempoh maks; log_not_found off; ) lokasi / ( # add_header Access-Control-Allow- Origin *; try_files $uri $uri/ /index.php?$query_string; ) lokasi ~* \.php$ ( try_files $uri = 404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix :/var/run/php/php7.0-fpm.sock; # sambungkan soket php-fpm fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; sertakan fastcgi_params; ) lokasi ~ /\.ht ( tolak semua; ) )
Simpan fail. Sekarang kita perlu menyemak sama ada terdapat sebarang ralat di dalamnya. Kami boleh melakukan ini sebagai satu pasukan.

Sudo nginx -t
Jika kami melihat maklumat seperti dalam tangkapan skrin, maka semuanya betul dan kami boleh meneruskan penyediaan. Jika anda mendapat sebarang ralat, anda patut menyemak semula fail konfigurasi anda.

Sekarang kita perlu mengaktifkan fail konfigurasi, dalam direktori /etc/nginx/sites-enabled/ kita perlu membuat symlink ( pautan simbolik). Jika anda memasang nginx dari awal, maka dalam direktori ini terdapat symlink ke fail lalai, yang telah dibincangkan di atas; anda boleh memadamkannya jika anda tidak memerlukannya. Pergi ke direktori yang dikehendaki.

Cd /etc/nginx/sites-enabled/
Sekarang kita dah masuk direktori yang dikehendaki. Mari buat symlink kami. Untuk mencipta, gunakan arahan ln dengan bendera -s, kemudian kami akan menunjukkan laluan ke konfigurasi project.local kami.

Sudo ln -s /etc/nginx/sites-available/project.local
Mari lihat symlink yang kami buat.

Untuk memastikan bahawa kita masih melakukan semuanya dengan betul, mari jalankan arahan itu sekali lagi.

Fail tuan rumah

Fail ini terletak di /etc/hosts. Kehadiran entri di dalamnya membolehkan anda menjalankan nginx menggunakan localhost sebagai domain. Dalam fail ini anda boleh menetapkan alias alternatif, contohnya untuk projek project.local kami, kami akan menetapkan domain project.local.

Buka fail dalam editor nano.

Sudo nano /etc/hosts
Anda akan mempunyai maklumat lain dalam fail ini, abaikan sahaja. Anda hanya perlu menambah baris seperti dalam tangkapan skrin saya.

Pemasangan php-fpm (>=7.0)

sudo aptitude install php-fpm
Menyemak versi yang dipasang, untuk berjaga-jaga, walaupun dalam Ubuntu 16.04.1 versi 7.0 berada dalam repositori.

Php-fpm7.0 -v

Jom pastikan semuanya ok. Mari mulakan php-fpm.

Perkhidmatan sudo bermula php7.0-fpm
Jika anda mengedit konfigurasi, jangan lupa untuk memulakan semula daemon. Ia berbuat demikian. Tetapi kita tidak akan memerlukannya.

Perkhidmatan Sudo php7.0-fpm dimulakan semula
Ini adalah pemasangan dan persediaan php-fpm selesai. Sungguh, itu sahaja. Ini bukan sihir; laluan ke soket php-fpm telah ditentukan dalam fail konfigurasi. Sudah tentu anda mungkin memerlukan beberapa sambungan php untuk pembangunan projek peribadi, tetapi anda boleh membekalkannya seperti yang diperlukan.

Sekarang mari pergi ke direktori dengan projek kami, saya ada di sepanjang laluan ini.

Cd /home/stavanger/code/project.local
Mari pergi ke direktori di atas dan buat kebenaran 777 (iaitu, kita akan lakukan hak penuh direktori dengan projek projek kami.local). Ini akan menyelamatkan kita daripada masalah yang tidak perlu pada masa hadapan.

Cd .. sudo chmod -R 777 project.local
Ini melengkapkan persediaan perisian, mari buat fail ujian dalam projek direktori kerja kami.local dan pastikan semuanya berfungsi. Saya akan mencipta fail index.php dengan kandungan ini.

Kami pergi ke penyemak imbas dan melihat bahawa semuanya berfungsi hebat untuk kami! Jurubahasa PHP termasuk.

Berkenaan dengan pembaca, Stavanger.

Pada masa ini, dua pelayan web telah mendapat yang paling popular. Ini ialah Apache dan Ngnix. Setiap daripada mereka mempunyai kebaikan dan keburukan sendiri. Apache telah dibangunkan kembali pada tahun 1995 dan pembangunannya tidak mengambil kira semua kemungkinan keperluan pengguna; ia menggunakan banyak memori dan sumber sistem, tetapi ia mudah untuk dikonfigurasikan. Nginx dibangunkan sedikit kemudian pada tahun 2002, dengan mengambil kira ralat Apache dan memfokuskan pada prestasi maksimum.

Kami tidak akan menerangkan secara terperinci tentang kebaikan dan keburukan kedua-dua pelayan web ini. Setiap daripada mereka mempunyai kawasan permohonan sendiri. Panduan ini akan merangkumi pemasangan Nginx Ubuntu 16.04. Walaupun saya akan bercakap tentang Ubuntu 16.04, semua langkah akan berfungsi untuk pengedaran lain juga. Menyediakan Nginx adalah sama di mana-mana, hanya arahan pemasangan yang berbeza.

Langkah pertama ialah memasang pelayan web itu sendiri pada sistem. Program ini berada dalam repositori rasmi, tetapi versinya sudah agak ketinggalan zaman, jadi jika anda mahukan versi terkini, anda perlu menambah PPA:

sudo apt-add-repository ppa:nginx/stable

Pada masa ini versi 1.10.0 tersedia dalam repositori rasmi dan 1.10.1 sudah tersedia dalam PPA yang stabil. Jika anda tidak memerlukan versi, anda boleh melakukannya tanpa PPA. Seterusnya, kemas kini senarai pakej dari repositori:

Dan pasang ngnix:

sudo apt pasang nginx

Selepas pemasangan pelayan Nginx selesai, tambahkan atur cara untuk dimulakan supaya ia bermula secara automatik:

sudo systemctl membolehkan nginx

Jika anda membuka penyemak imbas anda sekarang, anda akan melihat nginx berjalan, tetapi kami masih perlu mengkonfigurasinya.

Menyediakan Nginx Ubuntu

Menyediakan Nginx Ubuntu jauh lebih rumit daripada Apache. Di sini kami tidak akan mempertimbangkan semua pilihan dan keupayaan program, tetapi hanya akan bercakap tentang yang utama. Terdapat pelbagai konfigurasi di mana Nginx digunakan sebagai pelayan proksi, dan pelayan utama ialah Apache, tetapi kami tidak akan berminat dengan ini. Kami perlu memasang Nginx sebagai pelayan web kendiri.

Tetapan Nginx sangat berbeza - hanya terdapat satu fail konfigurasi utama dan fail untuk hos maya. Konfigurasi daripada setiap direktori, seperti dalam Apache, tidak disokong.

• /etc/nginx/nginx.conf- fail konfigurasi utama
• /etc/nginx/sites-available/*- fail konfigurasi untuk hos maya, dengan kata lain, untuk setiap tapak.
• /etc/nginx/sites-enabled/*- fail konfigurasi tapak yang diaktifkan.

Malah, fail konfigurasi untuk hos maya hanya dibaca daripada direktori yang didayakan tapak, tetapi ini mengandungi pautan ke tapak yang tersedia. Sistem ini dicipta untuk membolehkan anda melumpuhkan tapak tertentu buat sementara waktu tanpa memadamkan konfigurasinya. Semua fail lain mengandungi hanya pengisytiharan berubah-ubah dan tetapan standard yang tidak perlu diubah. Bagi nginx.conf, semua fail dari tapak yang membolehkan disertakan di dalamnya, dan oleh itu ia boleh mengandungi semua arahan yang sama. Sekarang mari kita lihat fail konfigurasi utama:

sudo vi /etc/nginx/nginx.conf

Seperti yang anda lihat, fail dibahagikan kepada beberapa bahagian. Struktur umum ialah:

pilihan global
peristiwa()
http(
pelayan (
lokasi()
}
pelayan()
}
mel()

• pilihan global bertanggungjawab ke atas pengendalian keseluruhan program.
• peristiwa- bahagian ini mengandungi tetapan untuk bekerja dengan rangkaian.
• http- mengandungi tetapan pelayan web. Harus mengandungi bahagian servier untuk penalaan halus setiap tapak.
• pelayan- bahagian ini mengandungi tetapan untuk setiap tapak yang dihoskan pada pelayan web.
• lokasi- bahagian lokasi hanya boleh terletak di dalam bahagian pelayan dan mengandungi tetapan hanya untuk permintaan tertentu.
• mel- mengandungi tetapan proksi mel.

Sebelum beralih kepada pilihan, kita perlu menyebut beberapa perkataan lagi tentang sintaks baris dalam fail konfigurasi. Ia kelihatan seperti ini:

nilai parameter nilai_tambahan...;

Baris mesti berakhir dengan ";" dan semua kurungan terbuka ( mesti ditutup.

Sekarang setelah anda mempelajari sedikit struktur global, anda boleh meneruskan untuk melihat parameter itu sendiri. Tidak banyak pilihan global:

• pengguna- pengguna bagi pihak yang program akan dijalankan.
• proses_pekerja- menetapkan berapa banyak proses yang perlu dilancarkan untuk menyelaraskan kerja program; anda tidak perlu melancarkan lebih banyak proses daripada anda mempunyai teras. Anda boleh menetapkan parameter auto dan kemudian program akan menentukan nombor ini sendiri.
• pid= fail pid program.
• worker_rlimit_nofile- menunjukkan bilangan maksimum fail yang boleh dibuka oleh program. Dikira sebagai proses_pekerja *sambungan_pekerja* 2.

Kami telah selesai dengan pilihan global; tidak banyak daripada mereka dan mereka tidak begitu menarik. Lebih menarik dari segi pengoptimuman ialah pilihan daripada bahagian acara:

• perhubungan_pekerja- bilangan sambungan yang boleh diproses oleh program secara serentak pada satu proses. Jika kita darab worker_process dengan parameter ini, kita mendapat bilangan maksimum pengguna yang boleh menyambung ke pelayan pada masa yang sama. Adalah disyorkan untuk menetapkan nilai dari 1024 kepada 4048.
• multi_accept- benarkan menerima banyak sambungan pada masa yang sama, tetapkan parameter hidup atau mati.
• guna- satu cara untuk bekerja dengan timbunan rangkaian. Lalai ialah tinjauan pendapat, tetapi pada Linux ia adalah lebih cekap untuk menggunakan epoll.

• hantar fail- gunakan kaedah penghantaran data fail hantar. Nilai dihidupkan.
• tcp_nodelay, tcp_nopush- hantar pengepala dan permulaan fail dalam satu pakej. Nilai dihidupkan.
• keepalive_timeout- tamat masa menunggu sebelum sambungan keepalive ditutup, lalai ialah 65, tetapi boleh dikurangkan kepada 10 saat.
• keepalive_requests- bilangan maksimum sambungan keepalive daripada satu pelanggan, disyorkan 100.
• reset_timedout_connection- memutuskan sambungan selepas tamat masa. Nilai dihidupkan.
• open_file_cache- maklumat cache tentang fail terbuka. Garis tetapan kelihatan seperti ini: open_file_cache max=200000 inactive=20s; maks - bilangan maksimum fail dalam cache, masa caching.
• open_file_cache_valid- menunjukkan selepas masa apa maklumat harus dipadamkan daripada cache. Contohnya: open_file_cache_valid 30s;
• open_file_cache_min_uses- maklumat cache tentang fail yang telah dibuka sekurang-kurangnya beberapa kali tertentu.
• open_file_cache_errors- maklumat cache tentang fail yang hilang, nilai pada.

Parameter utama telah disemak. Tetapan ini akan membantu anda mendapatkan prestasi yang lebih baik daripada nginx. Kami akan melihat bahagian pelayan dan lokasi dalam menyediakan hos maya.

Menyediakan pemampatan Gzip

Pemampatan kandungan diperlukan untuk mengurangkan saiz data yang dimuat turun oleh penyemak imbas. Ini mempercepatkan pemuatan tapak, tetapi menambah beban tambahan pada pemproses pelayan. Untuk mendayakan pemampatan dalam bahagian http anda perlu menambah parameter berikut:

Arahan ini juga boleh digunakan dalam bahagian pelayan, maka ia hanya akan berfungsi untuk domain maya yang ditentukan. Seterusnya, kami mengkonfigurasi parameter mampatan menggunakan pilihan berikut:

• gzip_min_length- panjang halaman minimum dalam bait di mana pemampatan mesti digunakan, contohnya, 1000 (1 kb)
• gzip_proxied- sama ada perlu untuk memampatkan permintaan proksi, mana-mana mengatakan bahawa segala-galanya perlu dimampatkan.
• gzip_types- jenis fail yang perlu dimampatkan, contohnya: text/plain application/xml application/x-javascript text/javascript text/css text/json;
• gzip_disable "msie6"- pemampatan tidak disokong dalam IE 6, jadi kami melumpuhkannya.
• gzip_comp_level- tahap mampatan, pilihan tersedia dari 1 hingga 10. 1 - minimum, 10 - mampatan maksimum.

Menyediakan hos maya

Seperti yang anda ketahui, pelayan boleh mengehoskan berbilang tapak web. Semua permintaan datang ke IP pelayan, dan nginx sudah menentukan, berdasarkan domain, kandungan yang perlu disampaikan. Agar nginx mengetahui kepunyaan domain itu, anda perlu mengkonfigurasi hos maya. Setiap hos biasanya diletakkan dalam fail yang berasingan. Konfigurasi hos terletak di bahagian pelayan, tetapi memandangkan semua fail dari tapak yang didayakan diimport ke bahagian http, logik struktur fail konfigurasi tidak rosak.

Mari lihat contoh persediaan:

vi /etc/nginx/sites-enabled/site.conf

• dengar 80- menyatakan bahawa sambungan harus didengari pada port 80, mungkin juga mengandungi pilihan pelayan lalai, yang bermaksud bahawa domain ini akan dibuka jika domain tidak dinyatakan dalam permintaan.
• root /var/www/html- direktori di mana fail tapak berada.
• indeks indeks.html- halaman yang akan dibuka secara lalai.
• nama pelayan- nama domain tapak.
• log_akses- fail untuk merekodkan log permintaan ke pelayan, boleh digunakan secara global dalam bahagian http dan untuk jenis fail tertentu di lokasi.
• log_ralat- log ralat pelayan web, boleh menerima parameter tambahan yang menunjukkan butiran log. amaran - maksimum, crit - hanya ralat kritikal.

Ini semua tetapan asas untuk hos maya, selepas itu ia akan berfungsi. Tetapi terdapat juga bahagian lokasi, yang membolehkan anda mengkonfigurasi tingkah laku pelayan untuk direktori dan fail tertentu. Sintaks lokasi ialah:

alamat lokasi()

Kedua-dua pertanyaan langsung mengenai akar pelayan dan ungkapan biasa boleh digunakan sebagai alamat. Untuk menggunakan ungkapan biasa, ia didahului oleh aksara "~". Mari lihat contoh di bawah, tetapi buat masa ini mari kita lihat arahan yang mungkin:

• benarkan- benarkan akses kepada lokasi untuk pengguna, semua - semua orang, anda juga boleh menentukan ip atau subnet.
• menafikan- menafikan akses ke lokasi, semua - untuk semua orang.
• fail percubaan- cuba membuka fail dalam susunan tertentu, membuka fail pertama yang ditemui. Sebagai contoh, pembinaan ini: $uri $uri/index.html $uri.html =404; mula-mula ia cuba membuka $uri, kemudian index.html, jika $uri.html tidak ditemui, dan kemudian, jika tiada fail preposisi wujud, ia memberikan ralat 404.
• tamat tempoh- menetapkan masa caching penyemak imbas untuk elemen yang diberikan, contohnya, 1d - satu hari, 2j - dua jam, 30s - 30 saat.

Sebagai tambahan kepada arahan utama ini, yang lain boleh digunakan di sini. Untuk butiran lanjut, lihat dokumentasi rasmi. Mari kita lihat beberapa contoh:

Jangan log favicon:

lokasi = /favicon.ico (
log_not_found off;
akses_log keluar;
}

Tolak akses kepada fail bermula dengan titik:

lokasi ~ /\. (
menafikan semua;
}

Cache fail biasa selama 90 hari:

lokasi ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2 |doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ (
akses_log keluar; log_not_found off; tamat tempoh 90h;

Topik mengkonfigurasi nginx dengan betul adalah sangat besar, dan, saya khuatir, ia tidak boleh dimuatkan dalam rangka kerja satu artikel tentang Habré. Dalam teks ini saya cuba bercakap tentang struktur umum konfigurasi; butiran dan butiran yang lebih menarik mungkin datang kemudian. :)

Titik permulaan yang baik untuk menyediakan nginx ialah konfigurasi yang disertakan dengan pengedaran, tetapi banyak keupayaan pelayan ini tidak disebut di dalamnya. Contoh yang lebih terperinci adalah di tapak web Igor Sysoev: sysoev.ru/nginx/docs/example.html. Walau bagaimanapun, mari kita cuba membina konfigurasi kita dari awal, dengan jambatan dan penyair. :)

Mari kita mulakan dengan tetapan umum. Mula-mula, kami akan menunjukkan pengguna yang bagi pihak nginx akan dijalankan (adalah buruk untuk berfungsi sebagai root, semua orang tahu :))

Sekarang mari kita beritahu nginx berapa banyak proses pekerja untuk bertelur. Biasanya, beberapa proses yang sama dengan bilangan teras pemproses dalam pelayan anda ialah pilihan yang baik, tetapi ia berbaloi untuk mencuba tetapan ini. Jika beban yang tinggi pada cakera keras dijangka, anda boleh melakukan satu proses untuk setiap cakera keras fizikal, kerana semua kerja masih akan dihadkan oleh prestasinya.

Proses_pekerja 2;

Mari kita jelaskan tempat untuk menulis log ralat. Kemudian, untuk pelayan maya individu, parameter ini boleh ditindih, supaya hanya ralat "global", contohnya, berkaitan dengan permulaan pelayan, akan muncul dalam log ini.

Error_log /spool/logs/nginx/nginx.error_log notis; # Tahap pemberitahuan "notis" sudah tentu boleh diubah

Sekarang datang bahagian "acara" yang sangat menarik. Di dalamnya anda boleh menetapkan bilangan maksimum sambungan yang akan diproses secara serentak oleh satu proses pekerja, dan kaedah yang akan digunakan untuk menerima pemberitahuan tak segerak tentang peristiwa dalam OS. Sudah tentu, anda hanya boleh memilih kaedah yang tersedia pada OS anda dan disertakan semasa penyusunan.

Tetapan ini boleh memberi kesan yang ketara pada prestasi pelayan anda. Mereka mesti dipilih secara individu, bergantung pada OS dan perkakasan. Saya hanya boleh memberikan beberapa peraturan am.

Modul untuk bekerja dengan acara:
- pilih dan tinjauan biasanya lebih perlahan dan memuatkan pemproses dengan agak berat, tetapi ia tersedia hampir di mana-mana dan berfungsi hampir selalu;
- kqueue dan epoll - lebih cekap, tetapi hanya tersedia pada FreeBSD dan Linux 2.6, masing-masing;
- rtsig ialah kaedah yang agak berkesan, dan disokong walaupun oleh Linux yang sangat lama, tetapi ia boleh menyebabkan masalah dengan sejumlah besar sambungan;
- /dev/poll - setakat yang saya tahu, ia berfungsi dalam sistem yang agak eksotik, seperti Solaris, dan agak berkesan di sana;

parameter sambungan_pekerja:
- Jumlah bilangan maksimum pelanggan yang dilayan akan sama dengan worker_processes * worker_connections;
- Kadangkala nilai yang paling ekstrem pun boleh berfungsi secara positif, seperti 128 proses, 128 sambungan setiap proses atau 1 proses, tetapi dengan parameter worker_connections=16384. Walau bagaimanapun, dalam kes kedua, anda kemungkinan besar perlu menala OS.

Peristiwa (
sambungan_pekerja 2048;
gunakan kqueue; # Kami ada BSD :)
}

Bahagian seterusnya adalah yang terbesar dan mengandungi perkara yang paling menarik. Ini ialah perihalan pelayan maya, dan beberapa parameter yang biasa digunakan untuk kesemuanya. Saya akan meninggalkan tetapan standard yang ada dalam setiap konfigurasi, seperti laluan ke log.

Http(
# Semua kod di bawah akan berada di dalam bahagian ini %)
# ...
}

Di dalam bahagian ini mungkin terdapat beberapa parameter yang agak menarik.

Panggilan sistem fail hantar agak baru untuk Linux. Ia membolehkan anda menghantar data ke rangkaian tanpa perlu menyalinnya ke dalam ruang alamat aplikasi. Dalam kebanyakan kes, ini meningkatkan prestasi pelayan dengan ketara, jadi sebaiknya sentiasa mendayakan pilihan fail hantar.

Parameter keepalive_timeout bertanggungjawab untuk masa maksimum untuk mengekalkan sambungan keepalive jika pengguna tidak meminta apa-apa padanya. Pertimbangkan cara tapak anda menghantar permintaan dan laraskan tetapan ini. Untuk tapak yang aktif menggunakan AJAX, adalah lebih baik untuk mengekalkan sambungan lebih lama; untuk halaman statik yang pengguna akan membaca untuk masa yang lama, adalah lebih baik untuk memutuskan sambungan awal. Perlu diingat bahawa dengan mengekalkan sambungan keepalive yang tidak aktif, anda menggunakan sambungan yang boleh digunakan secara berbeza. :)

Keepalive_timeout 15;

Secara berasingan, ia patut menyerlahkan tetapan proksi nginx. Selalunya, nginx digunakan dengan tepat sebagai pelayan proksi, jadi ia agak penting. Khususnya, masuk akal untuk menetapkan saiz penimbal untuk permintaan proksi tidak kurang daripada saiz tindak balas yang dijangkakan daripada pelayan bahagian belakang. Dengan hujung belakang yang perlahan (atau, sebaliknya, sangat cepat), adalah wajar untuk menukar tamat masa untuk menunggu respons daripada hujung belakang. Ingat, semakin lama tamat masa ini, semakin lama pengguna anda akan menunggu respons jika bahagian belakang perlahan.

Proxy_buffers 8 64k;
proxy_intercept_errors dihidupkan;
proxy_connect_timeout 1s;
proxy_read_timeout 3s;
proxy_send_timeout 3s;

Silap mata sikit. Sekiranya nginx menyediakan lebih daripada satu hos maya, adalah wajar untuk mencipta "hos maya lalai" yang akan memproses permintaan dalam kes di mana pelayan tidak dapat mencari alternatif lain menggunakan pengepala Hos dalam permintaan klien.

# hos maya lalai
pelayan (
dengar 80 lalai;
server_name localhost;
menafikan semua;
}

Ini mungkin diikuti oleh satu (atau beberapa) bahagian "pelayan". Setiap daripada mereka menerangkan hos maya (paling kerap, berasaskan nama). Bagi pemilik banyak tapak pada satu pengehosan atau untuk pengehos, mungkin terdapat sesuatu seperti arahan

Sertakan /spool/users/nginx/*.conf;

Selebihnya kemungkinan besar akan menerangkan hos maya mereka secara langsung dalam konfigurasi utama.

pelayan (
dengar 80;

# Sila ambil perhatian bahawa arahan nama_server boleh menentukan berbilang nama pada masa yang sama.
nama_server myserver.ru myserver.com;
access_log /spool/logs/nginx/myserver.access_log bermasa;
error_log /spool/logs/nginx/myserver.error_log warn;
# ...

Mari kita tetapkan pengekodan lalai untuk output.

Charset utf-8;

Dan katakan bahawa kami tidak mahu menerima permintaan daripada pelanggan yang panjangnya lebih daripada 1 megabait.

Saiz_badan_maks_pelanggan 1m;

Mari dayakan SSI untuk pelayan dan minta untuk menempah tidak lebih daripada 1 kilobait untuk pembolehubah SSI.

Si on;
ssi_value_length 1024;

Dan akhirnya, kami akan menerangkan dua lokasi, satu daripadanya akan membawa ke bahagian belakang, ke Apache yang berjalan pada port 9999, dan yang kedua akan menghantar imej statik dari sistem fail tempatan. Untuk dua lokasi ini tidak masuk akal, tetapi untuk bilangan yang lebih besar ia juga masuk akal untuk segera menentukan pembolehubah di mana direktori akar pelayan akan disimpan, dan kemudian menggunakannya dalam perihalan lokasi.

Hari ini kita akan melihat pada penyediaan hos maya yang menyediakan tapak dengan kandungan statik. Iaitu, tiada CGI, Perl, PHP atau apa sahaja. Semua contoh yang disebut dalam artikel merujuk kepada dan telah diuji Debian Linux 5.0 Lenny. Pemilik sistem lain tidak boleh keliru dengan ini dalam apa cara sekalipun, kerana hanya laluan ke fail konfigurasi boleh berubah, manakala kandungannya boleh digunakan untuk mana-mana sistem yang dijalankan Nginx.

Kaedah untuk menyimpan fail konfigurasi

Seperti yang anda ingat dari artikel sebelumnya, anda boleh menggunakan arahan dalam fail konfigurasi Nginx termasuk, yang boleh memasukkan kandungan fail lain dalam fail konfigurasi utama. Pendekatan ini menyediakan pentadbir dengan fleksibiliti konfigurasi pelayan tambahan, yang sering menjimatkan masa dan usaha.

Jika anda perasan, dalam fail konfigurasi utama /etc/nginx/nginx.conf tiada perkataan tentang konfigurasi pelayan maya. Tiada apa-apa yang dikatakan sama sekali tentang di mana akar dokumen pelayan terletak, pada port mana pelayan harus mendengar sambungan masuk, dsb. Walau bagaimanapun, baris terakhir dalam fail konfigurasi adalah seperti berikut:

Sertakan /etc/nginx/sites-enabled/*;

Iaitu, dari katalog /etc/nginx/sites-enabled kandungan semua fail dibaca dan digunakan pada konfigurasi pelayan semasa. Melihat ke dalam direktori yang disebutkan, anda akan melihat satu fail di sana lalai, yang merupakan pautan simbolik kepada fail /etc/nginx/sites-available/default. Ini juga merupakan pendekatan yang sangat mudah: anda tiba-tiba perlu melumpuhkan beberapa hos maya, anda hanya memadamkan pautan simbolik, dan tidak perlu mengalihkan fail ke sana ke mari.

Mencipta pelayan maya

Untuk "ketulenan percubaan" saya cadangkan untuk mengalih keluar pautan simbolik yang dibekalkan dengan pengedaran /etc/nginx/sites-enabled/default dan mulakan, boleh dikatakan, dengan batu tulis yang bersih.

Buat fail /etc/nginx/sites-available/myvhost dengan kandungan berikut:

Pelayan (dengar 80; nama_pelayan myvhost; access_log /var/log/nginx/myvhost.log; lokasi / ( root /var/www/myvhost/; indeks index.htm index.html; autoindex dihidupkan; ) )

Ini adalah konfigurasi paling mudah pelayan maya dalam Nginx. Sekarang mengenai parameter yang digunakan dalam susunan.

Pilihan pertama pelayan diikuti dengan pendakap kerinting memulakan bahagian baharu. Ia adalah dalam bahagian pelayan dan menerangkan konfigurasi semua pelayan maya dalam Nginx.

Pilihan dengar kami memberitahu Nginx nombor port yang mana pelayan maya kami harus mendengar sambungan. Nilai lalai pilihan ini ialah 80 , dan dalam contoh yang diberikan nilai ditakrifkan untuk kejelasan sahaja. Juga, menggunakan pilihan ini, anda boleh menentukan bukan sahaja nombor port, tetapi juga alamat antara muka rangkaian yang anda ingin "lampirkan" pelayan ini. Sebagai contoh, dua contoh berikut "menggantung" pelayan pada semua antara muka TCP/IP yang tersedia dalam sistem, pada port 8080:

Dengar 8080 dengar *:8080

Contoh berikut mengikat pelayan maya ke antara muka rangkaian tertentu dengan alamat IP 192.168.0.1, mendengar sambungan masuk pada port 8080:

Dengar 192.168.0.1:8080

Pilihan nama pelayan mentakrifkan nama pelayan maya yang digunakan apabila pelayan web menghuraikan pengepala HTTP hos, datang daripada pelanggan. Pilihan inilah yang melaksanakan konfigurasi hos maya berasaskan nama. Sebagai contoh, ini adalah serpihan konfigurasi dua hos maya pada satu pelayan akan kelihatan seperti:

Pelayan ( ... listen 80; server_name example-1.com ... ) server ( ... listen 80; server_name example-2.com ... )

Pilihan nama_server boleh mempunyai lebih daripada satu parameter, jadi anda boleh menentukan alias untuk pelayan anda, contohnya:

Server_name example-1.com www.example-1.com www1.example-1.com

Anda juga boleh menggunakan aksara asterisk untuk menggantikan sebarang jujukan aksara dalam nama pelayan:

Server_name example-1.com *.example-1.com

Dengan parameter log_akses kami bertemu di. Nilai parameter ini menentukan lokasi dan format fail log akses kandungan pelayan.

Pilihan lokasi patut dipertimbangkan dalam nota berasingan, jadi dalam artikel ini kita akan menyentuh sedikit sahaja makna dan keupayaannya, setakat yang mencukupi untuk mengkonfigurasi pelayan web statik. Menggunakan pilihan lokasi membolehkan anda menyesuaikan tingkah laku pelayan bergantung pada nilai URI yang diterima daripada klien. Jadi bahagian pelayan mungkin mengandungi beberapa bahagian lokasi bersarang yang menerangkan konfigurasi berdasarkan sebahagian daripada URI. Dalam contoh yang diberikan pada permulaan artikel, hanya satu lokasi ditakrifkan, yang akan sepadan dengan mana-mana URI yang diterima daripada klien, kerana mana-mana URI mengandungi aksara garis miring ke hadapan.

Sebagai contoh, jika anda perlu memastikan bahawa apabila subrentetan ditemui dalam URI /imej/, Nginx tidak mengakses direktori root pelayan, tetapi mencari fail dalam direktori /mnt/server2/var/www/images/, anda boleh menentukan dua lokasi berikut:

Lokasi / ( root /var/www/myvhost/; ) lokasi /images/ ( root /mnt/server2/var/www/; )

Contoh lokasi di atas menggunakan carian untuk subrentetan dalam rentetan URI. Iaitu, subrentetan /imej/ akan ditemui seperti dalam http://server/images/, dan http://server/my/images/. Jika anda memerlukan Nginx untuk melakukan carian tepat surat-menyurat, untuk ini anda boleh menggunakan simbol "=" , yang memaksa pelayan mencari dengan cara ini:

Lokasi = /images/ ( root /mnt/server2/var/www/; )

Anda juga boleh menentukan subrentetan yang sepatutnya anda gunakan memulakan URI. Untuk tujuan ini, binaan dua simbol digunakan "^~" :

Lokasi ^~ /images/ ( ... )

Sudah tentu, ungkapan biasa disokong dan memberikan fleksibiliti yang lebih besar apabila menerangkan lokasi. Lokasi berikut akan sepadan dengan semua URI yang mengandungi nama fail grafik pada penghujungnya (tidak sensitif huruf besar-besaran):

Lokasi ~* \.(gif|jpg|jpeg)$ ( ... )

Perkara yang sama, tetapi sensitif huruf besar-besaran:

Lokasi ~ \.(gif|jpg|jpeg)$ ( ... )

Dan sedikit tentang susunan pemprosesan pilihan lokasi dalam Nginx. Bertentangan dengan apa yang mungkin difikirkan oleh ramai pada pandangan pertama, ia tidak penting sama sekali (kecuali ungkapan biasa, sudah tentu) dalam susunan lokasi ditakrifkan dalam fail konfigurasi. Tidak kira bagaimana anda menukarnya, hasilnya akan sama. Apabila mencari lokasi yang diperlukan, Nginx mengikut algoritma berikut:

1. Mencari peraturan bermula dengan "=" . Sebaik sahaja peraturan sedemikian ditemui, carian selanjutnya akan dihentikan.
2. Carian dilakukan untuk peraturan "biasa", iaitu, ungkapan bukan biasa. Jika terdapat peraturan di kalangan mereka bermula dengan "^~" , carian selanjutnya akan dihentikan.
3. Ungkapan biasa diproses mengikut susunan ia muncul dalam fail konfigurasi.
4. Jika perlawanan ditemui mengikut titik 3, maka lokasi ini akan digunakan, jika tidak lokasi yang terdapat di titik 2 akan digunakan.

Pilihan akar nilainya mentakrifkan laluan ke akar dokumen pelayan maya pada sistem fail.

Menggunakan pilihan indeks anda boleh menentukan nama fail dokumen indeks yang Nginx akan "berikan" kepada pelanggan jika akses kepada direktori telah diminta. Jika tiada fail sedemikian dalam direktori dan pilihan dilumpuhkan untuk lokasi ini autoindex, maka pelanggan akan menerima kod HTTP sebagai tindak balas 403 , menunjukkan bahawa akses dinafikan.

Pilihan autoindex mengkonfigurasi tingkah laku Nginx jika fail indeks yang diminta tidak ditemui dalam direktori. Jika nilai pilihan autoindex, seperti dalam contoh di atas, ialah "pada", maka pelayan akan mengembalikan kandungan direktori kepada klien dalam bentuk senarai fail HTML. Secara lalai, autoindex dinyahdayakan, jadi berhati-hati dengannya agar tidak menyiarkan maklumat kritikal secara tidak sengaja untuk dilihat oleh semua orang.

Memulakan semula pelayan

Sekarang bahawa fail konfigurasi sudah sedia, anda perlu membuat pautan simbolik kepadanya dari direktori /etc/nginx/sites-enabled/ supaya apabila Nginx dimulakan semula, ia akan memasukkan kandungannya dalam konfigurasinya:

# ln -s /etc/nginx/sites-available/myvhost /etc/nginx/sites-enabled/myvhost

# mkdir /var/www/myvhost

Apa yang tinggal ialah untuk memulakan semula pelayan:

# /etc/init.d/nginx mulakan semula

Dan, jika semua tetapan selesai tanpa ralat, anda akan dapat menyambung ke pelayan maya Nginx pertama anda menggunakan pelayar web dan melihat indeks fail kosong dalam direktori akar pelayan. Cuba letakkan beberapa fail html statik dalam direktori /var/www/myshost dan kemudian aksesnya daripada penyemak imbas anda.

Dalam artikel seterusnya kita akan melihat konfigurasi pelayan SSL dalam Nginx.

Nginx? Tujuan, ciri, pilihan tetapan - ini adalah perkara yang setiap pembangun web harus biasa dengan untuk menguji kerja mereka.

Mari sebutkan satu perkataan tentang nginx

Alat ini mempunyai satu proses pekerja utama dan beberapa. Yang pertama berkaitan dengan membaca dan menyemak konfigurasi. Pengurusan proses kerja juga di bawah kawalannya. Tugas yang terakhir adalah untuk memproses permintaan masuk. Nginx menggunakan model berasaskan acara. Mekanisme khusus sistem pengendalian juga digunakan untuk mencapai pengedaran permintaan yang cekap secara langsung antara proses pekerja. Nombor mereka sentiasa ditunjukkan dalam fail konfigurasi. Nilai boleh sama ada ditetapkan atau ditetapkan secara automatik, berdasarkan bilangan teras pemproses yang boleh anda gunakan. Dalam nginx, sistem dan modul dikonfigurasikan menggunakan fail konfigurasi. Oleh itu, jika anda perlu mengubah sesuatu, maka anda perlu mencarinya. Ia biasanya terletak dalam arahan /etc/nginx (tetapi laluan mungkin berubah apabila menggunakan sistem lain) dan mempunyai sambungan .conf.

Permulaan, but semula dan log

Untuk melakukan ini, anda perlu membuat fail boleh laku berfungsi. Mengkonfigurasi pelayan nginx hanya boleh dilakukan apabila ia berjalan. Kawalan dijalankan dengan memanggil fail boleh laku dengan parameter -s. Untuk melakukan ini, gunakan notasi berikut:

isyarat nginx -s

Dalam kes ini, anda boleh menggantikan arahan berikut (mesti datang daripada pengguna yang melancarkan alat):

1. Berhenti. Digunakan untuk menutup kerja dengan cepat.
2. Tambah nilai. Perintah diperlukan untuk memuatkan semula fail konfigurasi. Maksudnya ialah sebarang perubahan tidak akan digunakan semasa fail sedang berjalan. Dan untuk mereka berkuat kuasa, but semula diperlukan. Sebaik sahaja isyarat ini diterima, proses utama akan mula menyemak ketepatan sintaks fail konfigurasi dan cuba menggunakan arahan di sana. Jika gagal, ia akan melancarkan semula perubahan dan berfungsi dengan tetapan lama. Jika semuanya berlaku dengan jayanya, maka proses pekerja baharu akan dilancarkan, dan yang lama akan dihantar permintaan untuk ditamatkan.
3. Berhenti. Digunakan untuk menyiapkan kerja yang lancar. Digunakan jika anda perlu menunggu sehingga permintaan semasa selesai diservis.
4. Buka semula. Tutup dan buka fail log.

Menggunakan Utiliti

Proses juga boleh dikonfigurasikan menggunakan alat Unix (utiliti bunuh akan dianggap sebagai contoh). Mereka biasanya menggunakan mekanisme untuk menghantar isyarat kepada proses secara langsung dengan data. Mereka dipautkan menggunakan ID. Data ini disimpan dalam fail nginx.pid. Katakan kami berminat dengan proses No. 134. Kemudian untuk kelancaran penyiapan kami perlu menghantar maklumat berikut:

bunuh -s BERHENTI 1628

Katakan kita mahu melihat senarai semua fail yang sedang berjalan. Kami menggunakan utiliti ps untuk ini. Perintah akan kelihatan seperti ini:

ps -kapak | grep nginx

Iaitu, seperti yang anda lihat, apabila menggunakan alat tambahan, ia menunjukkan bahawa ia sedang digunakan. Sekarang mari kita fokus pada cara konfigurasi nginx dilakukan.

Struktur fail konfigurasi

Pemasangan dan persediaan nginx menyediakan untuk bekerja dengan modul. Ia dikonfigurasikan menggunakan arahan yang dinyatakan dalam fail konfigurasi. Mereka mudah dan sekat. Jenis arahan pertama terdiri daripada nama dan parameter, yang dipisahkan oleh ruang, dan ditamatkan dengan koma bertitik (;). Blok mempunyai struktur yang serupa. Tetapi arahan ini, bukannya berakhir, mengandungi satu set arahan tambahan, yang diletakkan dalam pendakap kerinting ((arahan)). Jika ia boleh mengandungi nama dan parameter proses lain, maka pembinaan tersebut dipanggil konteks. Contohnya termasuk http, lokasi dan pelayan.

Menyajikan kandungan statik

Ini adalah salah satu tugas paling penting yang dihadapi oleh konfigurasi nginx. Dengan mengedarkan kandungan statistik yang kami maksudkan ialah imej dan halaman HTML (bukan dinamik). Katakan kita memerlukan kerja sekali sahaja untuk menyediakan kluster nix nginx. Adakah ia sukar dilakukan? Tidak, dan mari kita lihat contoh. Sebelum memulakannya, adalah perlu untuk memperincikan syarat tugas. Jadi, bergantung pada permintaan, fail akan datang dari direktori tempatan yang berbeza. Jadi, dalam /data/www kita mempunyai dokumen HTML. Dan direktori /data/images mengandungi imej. Konfigurasi optimum nginx dalam kes ini memerlukan penyuntingan fail konfigurasi, di mana anda perlu mengkonfigurasi blok pelayan di dalam http. Dua lokasi juga akan digunakan untuk sokongan.

Pelaksanaan: pelayan

Jadi, pertama kita perlu membuat direktori itu sendiri dan meletakkan fail dengan sambungan yang diperlukan di dalamnya (anda perlu menambah kandungan pada html). Kemudian buka fail konfigurasi. Secara lalai, ia sudah mengandungi beberapa blok pelayan, yang kebanyakannya dikomentari. Untuk mencapai hasil yang optimum, proses ini mesti dilakukan untuk semua komponen lalai. Kemudian kami menambah blok pelayan baharu menggunakan kod berikut:

Fail konfigurasi boleh berfungsi dengan beberapa blok sedemikian. Tetapi mereka mesti berbeza dalam nama dan port mereka yang melaluinya data diterima.

Perlaksanaan: lokasi

Ditakrifkan dalam pelayan:

Kehadiran tanda "/" diperlukan untuk membandingkan data yang diterima dan melihat sama ada alamat sedemikian daripada permintaan yang diproses ada di sini. Jika tiada masalah, kemudian nyatakan laluan /data/www ke fail yang diperlukan, yang terletak pada sistem setempat ini. Sekiranya terdapat padanan dengan beberapa blok, maka yang mempunyai awalan terpanjang dipilih. Dalam contoh yang diberikan, panjangnya adalah sama dengan satu, iaitu, ia akan digunakan secara eksklusif jika tiada "pesaing". Sekarang mari kita perbaikinya:

lokasi /gambar/ (

Bagaimana anda boleh tahu jika kami sedang mencari imej? Sekarang mari kita gabungkan semua perkembangan yang telah dibuat sebelum ini, dan konfigurasi pada masa ini kelihatan seperti ini:

lokasi /gambar/ (

Ini adalah pilihan yang berfungsi, yang merupakan standard. Pelayan ini boleh diakses pada komputer tempatan tanpa sebarang masalah jika anda pergi ke alamat: http://localhost/. Bagaimana semua ini akan berfungsi?

Bagaimana contoh itu berfungsi

Jadi, apabila permintaan tiba yang bermula dengan /images, pelayan akan menghantar fail dari direktori yang sepadan kepada pengguna. Jika tiada, maklumat yang menunjukkan ralat 404 akan dihantar. Jika nginx dikonfigurasikan pada komputer tempatan, maka apabila meminta http://localhost/images/example.png kami akan menerima fail yang lokasinya ialah /data/images/ contoh.png. Jika anda menetapkan satu aksara “/”, carian akan dijalankan dalam direktori /data/www. Tetapi kami hanya menukar konfigurasi. Untuk mula berfungsi, ia perlu dibut semula. Untuk melakukan ini, gunakan perintah muat semula nginx -s. Jika operasi biasa tidak dapat dilakukan, anda boleh mencari punca kerosakan dalam fail error.log dan access.log yang terletak dalam arahan /usr/local/nginx/logs.

Mencipta pelayan proksi mudah

Seseorang boleh mengatakan mengenai nginx - menyediakan objek ini adalah salah satu kegunaan biasa (dan agak mudah, dengan cara itu). Ia menggunakan prinsip pelayan yang menerima permintaan dan kemudian mengalihkannya ke tapak yang diperlukan. Selepas ini, respons dijangka daripada mereka, yang mengarahkan mereka kepada orang yang memberikan tugas itu. Jadi mari kita lihat contoh mencipta titik asas. Ia akan mengendalikan permintaan pengguna dan memberikan mereka imej daripada direktori tempatan. Jadi, ke blok http kami menambah pelayan lain dengan kandungan berikut:

Sekarang izinkan saya menguraikannya untuk anda: pelayan mudah sedang dibuat. Ia akan mendengar. Jika anda tidak menentukan dengar, pelayan akan berjalan pada 80. Semua permintaan dalam sistem fail tempatan yang diarahkan ke direktori /data/up1 akan dipaparkan (sudah tentu, ia perlu dibuat sebelum ini). Untuk dapat menyemaknya, anda perlu meletakkan fail index.html di sana. Dengan meletakkan arahan akar dalam konteks pelayan, kami boleh menggunakan lokasi di bawah sebarang syarat (kerana ini mengalih keluar sekatan akses). Sekarang kami sedang berusaha untuk mencipta pelayan proksi. Untuk berfungsi, kami memerlukan arahan proxy_pass, yang mana protokol, nama dan port objek akan ditentukan sebagai parameter (untuk sambungan tempatan, ini akan kelihatan seperti http://localhost:8080). Anda akan mendapat keputusan berikut:

proxy_pass http://localhost:8080;

lokasi /gambar/ (

Jika anda melihat kod dan menganalisisnya, anda mungkin dapati bahawa blok lokasi kedua telah diubah. Jadi, dalam kes ini ia boleh berfungsi dengan sambungan imej biasa. Ia boleh dipaparkan sedikit berbeza seperti ini:

lokasi ~ \.(gif|jpg|png)$ (

akar /data/imej;

Konfigurasi pelayan proksi terakhir kelihatan seperti ini:

proxy_pass http://localhost:8080/;

lokasi ~ \.(gif|jpg|png)$ (

akar /data/imej;

Ia akan menapis permintaan yang mempunyai sambungan yang ditentukan pada penghujungnya dan menghantarnya kepada orang yang meminta fail tersebut. Jangan lupa bahawa jika anda ingin menyemak fail konfigurasi, anda perlu memuatkannya semula. Dan percayalah, ini adalah persediaan nginx yang paling mudah. Jika anda membuka fail konfigurasi pelayan VKontakte atau syarikat besar lain, mereka akan mempunyai lebih banyak kod daripada perkataan dalam artikel ini.