מה זה Nginx ולמה משתמשים בו

כשאפליקציית ה-Node.js או ה-Python שלכם רצה על שרת, יש לה פורט פנימי שהיא מאזינה לו - נניח 3000 או 8000. אבל אתם לא באמת רוצים שהעולם יתחבר ישירות לפורט הזה. אתם רוצים משהו שיושב לפניו, מטפל בכל התעבורה הנכנסת, דואג להצפנה, ומחליט לאן לנתב כל בקשה. זה בדיוק התפקיד של Nginx, ואם עבדתם על אפליקציית ווב אמיתית, כמעט בטוח שהוא היה שם איפשהו בסטאק.

מה זה בכלל reverse proxy

reverse proxy הוא שרת שיושב בין המשתמשים לבין שרתי האפליקציה שלכם, ומקבל את כל הבקשות הנכנסות במקומם. במקום שהדפדפן של המשתמש יתחבר ישירות לשרת האפליקציה, הוא מתחבר ל-Nginx, ו-Nginx מחליט מה לעשות עם הבקשה - להגיש קובץ סטטי, להעביר אותה לשרת האפליקציה, או לנתב אותה לאחד מכמה שרתים לפי עומס.

היתרון הגדול הוא הפרדת אחריות. שרת האפליקציה שלכם צריך לדעת רק לענות על בקשות לוגיות עסקיות. את כל שאר העבודה - הצפנת TLS, דחיסה, caching, הגבלת קצב בקשות - אפשר להשאיר לשכבה שמתמחה בזה. זה גם אומר שאפשר להחליף או לשדרג את שרת האפליקציה בלי לגעת בשכבה שפונה החוצה לאינטרנט.

למה Nginx הפך לכל כך פופולרי

Nginx נכתב במקור כדי לפתור בעיה ספציפית - שרתי ווב ישנים יותר נתקעו כשהיה צריך לטפל באלפי חיבורים בו זמנית, כי כל חיבור קיבל תהליך או thread נפרד, וזה פשוט לא scale. Nginx נבנה מהיסוד עם ארכיטקטורה מונעת אירועים - event-driven - שמאפשרת לו לטפל באלפי חיבורים במקביל עם צריכת זיכרון נמוכה יחסית. זו הסיבה שהוא כל כך יעיל תחת עומס גבוה, ולמה הוא הפך לברירת המחדל בהרבה תשתיות ענן ומערכות בקנה מידה גדול.

מעבר לביצועים, Nginx גם גמיש להפליא. קובץ קונפיגורציה אחד יכול להגדיר אותו כשרת קבצים סטטיים, כ-reverse proxy, כ-load balancer, וכשער API - הכל באותו זמן, לפי הכתובת שאליה מגיעה הבקשה.

התפקידים ש-Nginx ממלא בסטאק אמיתי

בפרויקט ווב טיפוסי תראו את Nginx ממלא כמה תפקידים בו זמנית. הוא מגיש קבצים סטטיים - תמונות, CSS, JavaScript - ישירות מהדיסק, בלי לגרום לשרת האפליקציה לבזבז זמן עליהם. הוא מטפל ב-TLS termination, כלומר הוא זה שמנהל את תעודת ה-SSL ומצפין את התעבורה, כך ששרת האפליקציה מאחוריו יכול לדבר HTTP רגיל בלי הצפנה.

הוא גם משמש כ-load balancer - כשיש לכם כמה עותקים של אותה אפליקציה רצים במקביל, Nginx מפזר את הבקשות ביניהם, ואם אחד נופל, הוא פשוט מפסיק לשלוח אליו תעבורה. ולבסוף, הוא משמש כ-API gateway - נקודת כניסה אחת שמנתבת בקשות שונות לשירותים שונים לפי הנתיב, מה שנפוץ מאוד בארכיטקטורת מיקרו-שירותים.

Nginx מול Apache בקצרה

מי שמכיר את Apache בטח שואל מה ההבדל. Apache הוא שרת ווב ותיק ומוכח שעדיין נמצא בשימוש נרחב, אבל הארכיטקטורה שלו מבוססת יותר על תהליכים ו-threads לכל חיבור, מה שהופך אותו לפחות יעיל תחת עומסים מאוד גבוהים בהשוואה ל-Nginx. בהרבה מקרים היום, במיוחד באפליקציות מודרניות שמוגשות מ-containers או מיקרו-שירותים, Nginx פשוט מתאים יותר בזכות הביצועים והגמישות שלו כ-reverse proxy. זה לא אומר ש-Apache "רע", פשוט שהוא נבנה לתקופה אחרת עם הנחות שונות.

טיפ מעשי לסיום

מלכודת נפוצה אצל מתחילים היא לשכוח להגדיר timeouts וגדלי buffer נכונים כש-Nginx עובד כ-reverse proxy מול שרת אפליקציה איטי - זה יכול לגרום לבקשות להיתקע או להיכשל בלי הודעת שגיאה ברורה. שווה תמיד לבדוק את ה-logs של Nginx עצמו, לא רק את הלוגים של האפליקציה, כי הרבה פעמים הבעיה נמצאת בדיוק בשכבה הזאת שבין המשתמש לקוד שלכם.

אם אתם רוצים להבין איך כל השכבות האלה - שרת ווב, reverse proxy, שרת אפליקציה - מתחברות לכדי מערכת שלמה, מומלץ להסתכל על קורס צד שרת שבו בונים את זה מהיסוד.

Nginx הוא אחד הכלים שברגע שמבינים אותו, פתאום כל התשתית מאחורי אתר או API מתחילה להיראות הרבה יותר הגיונית. הוא לא מסובך כמו שהוא נראה במבט ראשון, פשוט צריך להבין את התפקיד שלו בשרשרת.

הצטרפו לקהילה בדיסקורד