ฉันมีประสบการณ์ในการใช้ linux แต่ไม่มีใครใช้ nginx ฉันได้รับมอบหมายให้ทำการค้นคว้าตัวเลือกการปรับสมดุลโหลดสำหรับแอปพลิเคชันเซิร์ฟเวอร์

ฉันใช้ apt-get เพื่อติดตั้ง nginx และทุกอย่างดูดี

ฉันมีคำถามสองสามข้อ

ความแตกต่างระหว่างโฟลเดอร์ที่มีไซต์และโฟลเดอร์ conf.d คืออะไร โฟลเดอร์ทั้งสองนั้นรวมอยู่ในการตั้งค่าเริ่มต้นสำหรับ nginx บทเรียนใช้ทั้ง มีไว้เพื่ออะไรและแนวทางปฏิบัติที่ดีที่สุดคืออะไร

โฟลเดอร์ที่เปิดใช้งานไซต์มีไว้เพื่ออะไร ฉันจะใช้มันได้อย่างไร

การกำหนดค่าเริ่มต้นอ้างอิงผู้ใช้ www-data หรือไม่ ฉันต้องสร้างผู้ใช้รายนั้นหรือไม่? ฉันจะให้สิทธิ์ที่ดีที่สุดแก่ผู้ใช้สำหรับการเรียกใช้ nginx ได้อย่างไร

โฟลเดอร์ * sites- มีการจัดการโดยและnginx_ensite nginx_dissiteสำหรับผู้ใช้ Apache httpd ที่พบนี้กับการค้นหาและรายการเทียบเท่าคือ/a2ensitea2dissite

sites-availableโฟลเดอร์สำหรับการจัดเก็บทั้งหมดของการกำหนดค่า vhost ของคุณหรือไม่ว่าพวกเขากำลังเปิดใช้งานอยู่

sites-enabledโฟลเดอร์มี symlinks ไปยังไฟล์ในโฟลเดอร์เว็บไซต์ที่มีอยู่ วิธีนี้ช่วยให้คุณสามารถเลือกปิดการใช้งาน vhost ได้โดยลบ symlink

conf.dทำงานได้ แต่คุณต้องย้ายบางสิ่งออกจากโฟลเดอร์ลบหรือเปลี่ยนแปลงเมื่อคุณต้องการปิดใช้งานบางอย่าง Abstraction ของโฟลเดอร์ sites- * ทำให้การจัดระเบียบเป็นเรื่องเล็ก ๆ น้อย ๆ และช่วยให้คุณจัดการได้ด้วยสคริปต์สนับสนุนแยกต่างหาก

(นอกเสียจากว่าคุณจะชอบฉันและเป็นหนึ่งในผู้ดูแลระบบเดเบียนหลายคนที่จัดการ symlink โดยตรงโดยไม่ทราบเกี่ยวกับสคริปต์ ... )

ฉันต้องการที่จะเพิ่มคำตอบก่อนหน้านี้ที่สำคัญที่สุดคือไม่ว่าคุณจะเรียกไดเรกทอรีที่ (คิดว่าคือการประชุมที่มีประโยชน์มาก) nginx.confแต่สิ่งที่คุณใส่จริงใน ตัวอย่างการกำหนดค่า:

http {
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*.conf;
    include /etc/nginx/sites-enabled/my_own_conf;
...
}

สั่งเพียงใช้ที่นี่เป็นรวมจึงไม่มีความแตกต่างภายในระหว่างเช่นและconf.d/sites-enabled/

จากเอกสารข้างต้น:

Syntax:     include file | mask;
Default:    —
Context:    any

Includes another file, or files matching the specified mask, 
into configuration. Included files should consist of 
syntactically correct directives and blocks.

ดังนั้นเพื่อตอบคำถามเดิม: ไม่มีความแตกต่างภายในและคุณอาจใช้ในวิธีที่ดีที่สุดเท่าที่จะทำได้โดยจดจำคำแนะนำจากคำตอบอื่น ๆ และโปรดอย่าลืมเลือกคำตอบ 'ถูกต้อง'

โดยทั่วไปแล้วsites-enabledโฟลเดอร์จะใช้สำหรับการกำหนดโฮสต์เสมือนในขณะที่conf.dใช้สำหรับการกำหนดค่าเซิร์ฟเวอร์ทั่วโลก หากคุณสนับสนุนเว็บไซต์หลายแห่งเช่นโฮสต์เสมือนแต่ละเว็บไซต์จะได้รับไฟล์ของตัวเองดังนั้นคุณสามารถเปิดใช้งานและปิดการใช้งานได้ง่ายมากโดยการย้ายไฟล์เข้าและออกsites-enabled(หรือการสร้างและลบ symlink ซึ่งอาจเป็นไปได้ว่า ความคิดที่ดีกว่า)

ใช้conf.dสำหรับสิ่งต่าง ๆ เช่นการโหลดโมดูลไฟล์บันทึกและสิ่งอื่น ๆ ที่ไม่เฉพาะเจาะจงกับโฮสต์เสมือนเดียว

การกำหนดค่าเริ่มต้นอ้างอิงผู้ใช้ www-data หรือไม่ ฉันต้องสร้างผู้ใช้รายนั้นหรือไม่?

คุณควรให้ nginx ทำงานในฐานะผู้ใช้ที่ไม่ใช่รูท นี่คือในบางกรณีชื่อwww-dataแต่คุณสามารถตั้งชื่อมันทุกอย่างที่คุณต้องการ

ฉันจะให้สิทธิ์ที่ดีที่สุดแก่ผู้ใช้สำหรับการเรียกใช้ nginx ได้อย่างไร

ฉันไม่ค่อยมั่นใจในคำตอบสำหรับคำถามนี้ (ฉันไม่ได้ใช้งาน nginx ในตอนนี้) แต่ถ้ามันเป็นอะไรอย่าง Apache คำตอบก็คือwww-dataผู้ใช้ต้องการเพียงสิทธิ์ในการอ่านไฟล์สแตติก (และอ่าน + ดำเนินการในไดเรกทอรี) ) ที่คุณกำลังให้บริการหรืออ่าน / ดำเนินการอนุญาตในสิ่งต่าง ๆ เช่นสคริปต์ CGI และไม่มีสิทธิ์อื่นใด

เกิดอะไรขึ้น?

คุณต้องใช้ Debian หรืออูบุนตูตั้งแต่ชั่วร้าย sites-available / sites-enabledตรรกะไม่ได้ถูกใช้โดยบรรจุภัณฑ์ต้นน้ำของ Nginxจากhttp://nginx.org/packages/

ในทั้งสองกรณีทั้งสองจะถูกนำมาใช้เป็นที่ประชุมกำหนดค่าด้วยความช่วยเหลือของมาตรฐานสั่งในinclude/etc/nginx/nginx.conf

นี่เป็นตัวอย่างข้อมูล/etc/nginx/nginx.confจากแพ็คเกจต้นน้ำอย่างเป็นทางการของ nginx จาก nginx.org:

http {
    …
    include /etc/nginx/conf.d/*.conf;
}

นี่เป็นตัวอย่างข้อมูล/etc/nginx/nginx.confจาก Debian / Ubuntu :

http {
    …
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

ดังนั้นจากมุมมองของ NGINX ที่แตกต่างกันเท่านั้นที่จะเป็นไปได้ว่าไฟล์จากconf.dได้รับการประมวลผลเร็วและเป็นเช่นถ้าคุณมีการกำหนดค่าที่เงียบขัดแย้งกับแต่ละอื่น ๆ แล้วผู้ที่มาจากอาจจะมีความสำคัญมากกว่าผู้ที่อยู่ในconf.dsites-enabled

conf.dปฏิบัติที่ดีที่สุดคือ

คุณควรใช้/etc/nginx/conf.dเนื่องจากเป็นแบบแผนมาตรฐานและควรทำงานได้ทุกที่

หากคุณต้องการปิดการใช้งานเว็บไซต์เพียงแค่เปลี่ยนชื่อไฟล์ให้ไม่มี.confส่วนต่อท้ายง่ายตรงไปตรงมาและป้องกันข้อผิดพลาด:

sudo mv -i /etc/nginx/conf.d/default.conf{,.off}

หรือตรงกันข้ามเพื่อเปิดใช้งานไซต์:

sudo mv -i /etc/nginx/conf.d/example.com.conf{.disabled,}

หลีกเลี่ยงsites-available& sites-enabledค่าใช้จ่ายทั้งหมด

ฉันเห็นว่าไม่มีเหตุผลที่จะใช้sites-available/ sites-enabled:

• บางคนได้กล่าวถึงnginx_ensiteและnginx_dissiteสคริปต์ - ชื่อของสคริปต์เหล่านี้เลวร้ายยิ่งกว่าส่วนที่เหลือของความล้มเหลวนี้ - แต่สคริปต์เหล่านี้ก็ไม่มีที่จะพบ - พวกเขากำลังขาดจากnginxแพคเกจแม้ใน Debian (และอาจเป็นใน Ubuntu) และไม่ปรากฏอยู่ในแพ็คเกจของพวกเขาเองรวมทั้งคุณต้องการสคริปต์ของบุคคลที่สามที่ไม่ได้มาตรฐานทั้งหมดเพื่อย้ายและ / หรือเชื่อมโยงไฟล์ระหว่างสองไดเรกทอรีหรือไม่!

• และหากคุณไม่ได้ใช้สคริปต์ (ซึ่งอันที่จริงแล้วเป็นตัวเลือกที่ฉลาดตามข้างบน) แล้วคุณจะจัดการกับปัญหาได้อย่างไร:

  • คุณสร้างลิงก์สัญลักษณ์จากsites-availableถึงsites-enabledหรือไม่
  • คัดลอกไฟล์หรือไม่
  • ย้ายไฟล์หรือไม่
  • แก้ไขไฟล์ที่อยู่ในsites-enabled?

ด้านบนอาจดูเหมือนว่ามีปัญหาเล็กน้อยที่จะแก้ไขจนกระทั่งหลายคนเริ่มจัดการระบบหรือจนกว่าคุณจะตัดสินใจได้อย่างรวดเร็วเพียงลืมเรื่องนี้ไปหลายเดือนหรือหลายปี ...

ซึ่งนำเราไปยัง:

• จะปลอดภัยที่จะลบไฟล์จากsites-enabled? มันเป็นลิงค์อ่อนหรือไม่? ลิงค์ยาก? หรือเฉพาะการกำหนดค่าเท่านั้น ตัวอย่างสำคัญของการกำหนดค่านรก

• ไซต์ใดถูกปิดใช้งาน (ด้วยconf.d, เพียงแค่ทำการค้นหาไฟล์ที่ไม่ลงท้ายด้วย.conf- find /etc/nginx/conf.d -not -name "*.conf"หรือใช้grep -v.)

ไม่เพียง แต่ทั้งหมดข้างต้น แต่ยังทราบเฉพาะincludeคำสั่งที่ใช้โดย Debian / Ubuntu - /etc/nginx/sites-enabled/*- ไม่มีคำต่อท้ายชื่อไฟล์ที่ระบุไว้สำหรับแตกต่างสำหรับsites-enabledconf.d

• สิ่งนี้หมายความว่าถ้าวันหนึ่งคุณตัดสินใจที่จะแก้ไขไฟล์หนึ่งหรือสองไฟล์อย่างรวดเร็ว/etc/nginx/sites-enabledและคุณemacsสร้างไฟล์สำรองอย่างdefault~ทันทีทันใดคุณมีทั้งสองอย่างdefaultและdefault~รวมเป็นการตั้งค่าที่ใช้งานซึ่งขึ้นอยู่กับคำสั่งที่ใช้ คำเตือนใด ๆ และทำให้เซสชันการดีบักเป็นเวลานานขึ้น (ใช่มันเกิดขึ้นกับฉันมันเป็นช่วงแฮ็คฮ็อตและฉันงงเลยว่าทำไมความลับของฉันถึงไม่ทำงาน)

ดังนั้นฉันมั่นใจว่าsites-enabledเป็นความชั่วร้ายที่บริสุทธิ์!