בדיקות בריאות של HAProxy עבור פרוקסי העברה של Squid
בנו בדיקת בריאות של HAProxy שמדברת עם פרוקסי העברה ומבחינה בין נגישות המאזין, קבלת CONNECT ושליפה מהמקור.
קובץ בשם /check.txt במארח פרוקסי נשמע כיעד בריאות מובן מאליו. המלכוד הוא שהמאזין המפורש להעברה של Squid אינו אתר אינטרנט רגיל שמגיש את שורש המסמכים של אותו מארח.
בקשה בסגנון מקור כמו HEAD /check.txt HTTP/1.1 משמיטה את היעד המוחלט שמצופה לבקשת HTTP רגילה דרך פרוקסי העברה. בהתאם לתצורה, היא עשויה להידחות או להיות מטופלת על ידי שירות מקומי אחר. כל אחת מהתוצאות עשויה לספר לכם פחות ממה שהמסך מרמז.
בחרו את השירות שצריך להישאר זמין
| בדיקה | ראיה שימושית |
|---|---|
| חיבור TCP למאזין הפרוקסי | תהליך נגיש מקבל את החיבור הזה. |
| CONNECT ליעד נשלט | הפרוקסי מקבל את בקשת המנהרה הזו. |
| שליפת HTTP דרך הפרוקסי | נתיב הבקשה שנבחר יכול להחזיר תגובה צפויה. |
במקרה השלישי הבקשה זקוקה ליעד, למשל:
HEAD http://probe.example.internal/proxy-ready HTTP/1.1
Host: probe.example.internalשם המארח הוא להמחשה בלבד. השתמשו בנקודת קצה נשלטת שהפרוקסי יכול לפתור ושאליה הותר לו להגיע בכוונה. http-check send של HAProxy תומך בבחירת שיטה, URI, גרסה וכותרות; הגדירו את הבקשה הזו במפורש במקום לרשת ללא שינוי דוגמה של שרת מקור.
HEAD יכול לבדוק מצב תגובה וכותרות. הוא אינו יכול לאמת גוף תגובה שלעולם אינו מועבר. אם חוזה הבריאות דורש סמן בגוף, בחרו בבדיקת GET מתאימה ואמתו את הסמן הזה.
שמרו על חשבון הבדיקה והגבלות המקור צרים כשמדובר באימות פרוקסי. פטור של כל המאזין מאימות כדי לקבל סימן ירוק משנה את השירות שמוגן.
לבסוף, החליטו מה בדיקה כושלת צריכה להסיר. תקלת מקור נשלטת עלולה להכשיל בו-זמנית את בדיקת ההעברה של כל פרוקסי. ייתכן שזו בדיוק התלות שברצונכם למדוד, או סיבה להחזיק את בריאות המאזין ואת הזמינות מקצה לקצה כאותות נפרדים.