אוטומציה בלינוקס: מ-cron ו-Bash ועד Ansible ו-systemd

אינפורמטק דיגיטל » Recursos » אוטומציה בלינוקס: מ-cron ו-Bash ועד Ansible ו-systemd

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

המערכת האקולוגית של לינוקס תוכננה לכך במשך עשרות שנים: אוטומציה של משימות בצורה אמינה, גמישה ומאובטחתמפקודות cron קלאסיות ו-at, דרך anacron, ועד טיימרים של systemd והליגות הגדולות עם Ansible, יש לכם מגוון רחב של כלים שיכסו הכל, החל מהסקריפט הפשוט ביותר ועד לתזמור של מאות שרתים. במדריך זה, נאחד את כל החלקים הללו ונהפוך אותם למעשיים בעזרת הסברים מפורטים ודוגמאות ברורות.

מה המשמעות של אוטומציה בלינוקס ולמה זה אמור לעניין אותך?

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

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

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

בפעילות היומיומית, אוטומציה בלינוקס מבוססת בדרך כלל על מספר עמודי תווך: סקריפטים של Bash, cron/anacron, at, טיימרים של systemd וכלי ניהול תצורה כמו Ansibleכל אחד מהם מכסה סוג אחר של צורך, עליו נבחן בפירוט.

קרון: הקלאסיקה החיונית של אוטומציה תקופתית

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

מקור השם שלו כרונוס, זמן ביווניתVixie Cron קיים ביוניקס מאז סוף שנות ה-70. רוב ההפצות המודרניות (דביאן, אובונטו, פדורה וכו') משתמשות בגרסה כלשהי של Vixie Cron, שנבדקה היטב ויציבה. עבור סביבות ייצור, זהו רכיב בסיסי, כמעט חיוני כמו הליבה עצמה.

שימוש ב-cron מאפשר לך להפוך דברים לאוטומטיים כמו גיבויים ליליים, סבב יומנים, משימות ניטור, סקריפטים לתחזוקה או יצירת דוחותהפילוסופיה פשוטה: אתם מגדירים מה להריץ ומתי, ו-cron דואג לשאר, ללא חלונות גרפיים או סיפורים.

יתר על כן, cron זמין כמעט בכל מערכת דמוית יוניקס, כך מה שלומדים עם cron שימושי עבור סביבות עבודה רבות ושונות.משרת VPS זול ועד שרת ארגוני.

ארכיטקטורת cron של לינוקס: daemon, crontabs וספריות מיוחדות

כדי להשתמש ב-Cron ביעילות, כדאי להבין כיצד הוא בנוי באופן פנימי. במונחים כלליים, המערכת בנויה סביב הדמון crond, קבצי crontab ומספר ספריות מיוחדות. המנוהל על ידי המערכת.

הדמון cron מתחיל יחד עם המערכת (בדרך כלל דרך systemd או ה-init המתאים) ו- הוא נשאר ער, ובודק כל דקה אם יש משימות שיופעלו.כאשר הוא מזהה ששורה תואמת את הדקה הנוכחית, הוא מפעיל את הפקודה המשויכת בתהליך מעטפת חדש.

לכל משתמש במערכת יכול להיות קובץ תזמון משלו, המכונה crontab. קבצי crontab של משתמשים מאוחסנים בדרך כלל בנתיבים כגון /var/spool/cron/ או /var/spool/cron/crontabs/תלוי בהפצה. חשוב לא לערוך אותם ידנית, אלא באמצעות הפקודה. crontab, אשר מאמת את התחביר ומודיע לדמון על שינויים.

בנוסף ל-crontabs של משתמשים, ישנם מנגנוני cron שתוכננו עבור המערכתקובץ /etc/crontab, ספריית /etc/cron.d/, וספריות תקופתיות כגון /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, ו- /etc/cron.monthly. ספריות אחרונות אלו מכילות סקריפטים שהמערכת מפעילה באופן תקופתי באמצעות כלים כגון anacron או run-parts.

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

תחביר crontab: חמשת השדות והאופרטורים שלהם

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

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

בנוסף, מימושים רבים של cron מקבלים קיצורי דרך מיוחדים כמו @daily, @hourly, @weekly, @monthly, @reboot ודומיהם. כינויים אלה מפשטים משימות נפוצות, כך שאפילו לא צריך לזכור את סדר השדות.

כאשר אתה עובד עם הקובץ /etc/crontab או עם /etc/cron.d/, נוסף שדה שישי כדי לציין את המשתמש שתחתיו תפעל המשימה.זהו מפתח עבור משימות מערכת שצריכות להיות מופעלות כחשבונות root או חשבונות שירות אחרים.

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

ניהול crontab מקצועי: עריכה, רישום וניהול גרסאות

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

נוהג מומלץ מאוד בסביבות רציניות הוא שמירה על תוכן crontab בקבצי טקסט עם גרסאות שונות באמצעות Gitבדרך זו תוכלו לבדוק מי שינה מה ומתי, להשוות גרסאות קודמות ולשחזר במהירות תצורה קודמת אם משהו נשבר לאחר שינוי.

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

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

דוגמאות נפוצות למשימות אוטומטיות עם cron

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

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

בתחום הפיתוח ומסדי הנתונים, גם ל-cron יש פוטנציאל רב. לדוגמה, משימות מתוזמנות משמשות ל... לבצע גיבויים של מסדי נתונים, להפעיל סקריפטים שיוצרים מחדש מדדים או לייצא דוחות לקבצי CSVאו אפילו לתזמר מסלולי עיבוד נתונים קטנים.

כל זה כמעט תמיד נתמך על ידי סקריפטים של Bash או שפות אחרות שעושות את העבודה בפועל, בעוד ש-cron דואג ל"מתי". הפרדת האחריות הזו שומרת על ה-crontab נקי ועל הלוגיקה העסקית הכלואה בקבצים נפרדים.

משתני סביבה ב-cron: מקור השגיאות הקלאסי

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

משמעות הדבר היא שסקריפטים רבים שעובדים בצורה מושלמת כאשר הם מופעלים ידנית נכשלים תחת cron מכיוון הם לא יכולים למצוא את הקבצים הבינאריים, הם לא יכולים לאתר נתיבים יחסיים, או שהם תלויים במשתני סביבה שאינם קיימים.הפתרון פשוט: הגדירו במפורש את PATH וכל משתנה נחוץ אחר בתוך ה-crontab עצמו או בסקריפט.

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

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

/etc/crontab, /etc/cron.dy הן ספריות מחזוריות

בנוסף ל-crontabs בודדים, לינוקס מציעה גם crontab של המערכת נמצא בדרך כלל ב-/etc/crontabקובץ זה שונה מקבצי משתמש בכך שהוא כולל שדה נוסף לציון החשבון שבאמצעותו תופעל הפקודה, דבר בסיסי למשימות גלובליות.

קובץ זה מגדיר בדרך כלל, בין היתר, ביצוע הסקריפטים ב-/etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly ו-/etc/cron.monthlyבמערכות רבות, פעולות אלו מועברות לכלי עבודה כמו anacron, אשר מבטיחים שהמשימות מבוצעות גם אם המחשב אינו מופעל בזמן המדויק.

מַדרִיך /etc/cron.d/ הוא מארח קבצי crontab נוספים, שבדרך כלל מותקנים על ידי חבילות מערכת או כלים חיצוניים. כל קובץ עוקב אחר אותו פורמט כמו /etc/crontab, כולל שדה המשתמש. זוהי הדרך המומלצת ל... הוסף משימות מערכת מבלי לגעת בקרונטאב הראשי.זה משפר את התחזוקה ומונע התנגשויות במהלך עדכונים.

תהליך העבודה האופייני הוא שדמון ה-cron בודק את הקבצים הללו מעת לעת, ובשילוב עם anacron או run-parts, זה מפעיל את הסקריפטים הכלולים בספריות התקופתיות בזמן המתאים להם.כמנהל, אתה רק צריך להשאיר את הסקריפטים שלך מוכנים כראוי במקום הנכון.

אנאקרון: כאשר הציוד אינו דולק תמיד

מגבלה ידועה של cron היא שאם המחשב כבוי כאשר מגיע הזמן להריץ משימה, הביצוע הזה אובד. אנאקרון נוצר בדיוק כדי למלא את הפער הזה.במיוחד במכונות שאינן דולקות 24/7, כגון מחשבים ניידים או מחשבים שולחניים משרדיים.

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

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

במערכות מודרניות רבות, אם anacron קיים, הוא אחראי על הסקריפטים ב-/etc/cron.daily, /etc/cron.weekly, ו-/etc/cron.monthly, בעוד ש-cron מטפל במשימות עדינות ותכופות יותר. שילוב זה מאפשר זאת. מערכות האוטומציה צריכות להיות חזקות גם במכונות שמושבתות לעתים קרובות..

הפקודה at: ביצוע חד פעמי בעתיד

בעוד ש-cron ו-anacron מתמקדים במשימות חוזרות, הפקודה זה מכסה מקרה פשוט ושימושי מאוד: תזמון פקודה להפעלה פעם אחת בלבד בזמן עתידי מסוים. זה כמו להשאיר פתק דבוק למערכת כדי לגרום לה לעשות משהו "מחר בשעה 9:30" או "בעוד שעתיים".

התחביר של `at` די ידידותי למשתמש ומאפשר ביטויי זמן טבעיים. לאחר שמגדירים את העבודה, המערכת מאחסנת אותו בתור ומבצעת אותו בזמן המתאים.לאחר מכן, המשימה נעלמת, בניגוד ל-cron, ששומר על המשימה עד שתשנה או תמחק אותה.

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

בשילוב עם סקריפטים טובים, `at` הופך לתו כללי אלגנטי שרבים מהמשתמשים שוכחים שקיימים, אך זה יכול לפשט מאוד את חיי היומיום שלך כאשר יצירת ערך cron חדש אינה משתלמת..

טיימרים של systemd: האלטרנטיבה המודרנית ל-cron

בהפצות מודרניות המשתמשות ב-systemd (אובונטו, דביאן, פדורה, CentOS ורבות אחרות), יש דרך נוספת לתזמן משימות: טיימרים של systemdבמקום להסתמך על crontabs, כאן אתה מגדיר יחידות שירות (.service) ויחידות טיימר (.timer) ש-systemd מנהלת בדיוק כמו שירותים אחרים.

טיימרים של Systemd בולטים מכיוון הם משתלבים בצורה מושלמת עם שאר המערכת האקולוגית של המערכת.ניתן לצפות בסטטוס, ביומנים ובתלות באמצעות אותם כלים מוכרים (journalctl, systemctl וכו'). זה אידיאלי עבור משימות מורכבות שצריכות להתחיל לאחר שירותים אחרים, לאכוף מדיניות הפעלה מחדש או לתחזק יומנים מפורטים.

טיימר טיפוסי מורכב מקובץ שירות המגדיר מה מבוצע (סקריפט, קובץ בינארי, פעולה ספציפית) ומקובץ טיימר המציין מתי ובאיזו תדירות הוא מופעל. Systemd מציע ביטויי לוח שנה גמישים ואפשרויות כגון persistence.אשר מבטיחים שהעבודה תתבצע לאחר כיבוי אם היא "דילגה".

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

בסופו של דבר, אין מלחמה בין שתי הגישות: ניתן להשתמש ב-cron למשימות פשוטות וב-טיימרים למשימות מורכבות., ללא כל בעיה של קיום משותף באותה מערכת.

אבטחה ובקרת גישה ב-cron

מכיוון ש-cron יכול לבצע כמעט כל פקודה עם הרשאות המשתמש המתאימות, אבטחה היא נושא קריטי. לינוקס משלבת מנגנוני בקרה המבוססים על הקבצים /etc/cron.allow ו- /etc/cron.denyאשר קובעים אילו משתמשים יכולים להשתמש ב-cron.

בהתאם לתצורה, המערכת יכולה לאפשר cron רק לאלו הנמצאים ברשימה הלבנה, או למנוע זאת במפורש לאלו הנמצאים ברשימה השחורה. ניהול נכון של קבצים אלה חיוני בסביבות מרובות משתמשים או בשרתים חשופים.כאשר לא רצוי שאף חשבון ירווה משאבים במשימות שתוכננו בצורה גרועה.

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

בהקשרים מתקדמים יותר, כלים כמו SELinux או AppArmor יכולים להוסיף שכבות נוספות של שליטה על מה שתהליכים המופעלים על ידי cron יכולים לעשות, ובכך לחזק עוד יותר את רמת האבטחה של המערכת.

ניפוי באגים בעבודות cron: מתודולוגיה ושגיאות אופייניות

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

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

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

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

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

שיטות עבודה מקצועיות טובות עם cron

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

כלל זהב הוא תמיד להפנות את הפלט של כל משימה לקובץ יומן /dev/nullאם לא תעשה זאת, cron ינסה לשלוח את הפלט הזה בדוא"ל למשתמש, מה שעלול למלא את תיבות הדואר של ה-root או פשוט ללכת לאיבוד אם מערכת הדואר אינה מוגדרת, מה שמקשה ביותר על האבחון.

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

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

לבסוף, מומלץ להוסיף תיאור ברור לכל שורה בקרונטאב ולשמור את הקובץ. תחת בקרת גרסאות עם Git או מערכות דומותככל שיעבור הזמן (או שהמנהל יתחלף), התגובות הללו והיסטוריית השינויים יהיו זהב טהור.

סקריפטים של Bash: המנוע שמפעיל את האוטומציות

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

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

ברמה המעשית, סקריפט Bash טיפוסי מתחיל בשורה #! / bin / bash כדי לציין את הקליפה שצריכה לפרש אותה, להגדיר משתנים, לבצע פקודות, להשתמש בתנאי הפעלה ולולאות, ולהוסיף הודעות אינפורמטיביות באמצעות הד כדי שנדע מה קורה.

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

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

דוגמה מעשית: גיבוי יומי עם Bash ו-cron

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

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

אם משלבים זאת גם עם הצפנת גיבויים, השימוש ב- tar/gz בלינוקס או העברה מאובטחת לשרת אחר באמצעות VPN או מנהרות SSH, ניתן להגדיר אסטרטגיית גיבוי טובה בלי הרבה טרחה, בהסתמך אך ורק על כלי לינוקס קלאסיים.

ניתן לשמור את הסקריפט הזה בספרייה כמו /usr/local/sbin או בתיקיית הסקריפטים שלך ולתת לו הרשאות ביצוע. לאחר מכן, השתמש ב-cron כדי להריץ את התוכנית. ביצוע אוטומטי בזמן שהשרת אינו תחת עומסלדוגמה, כל לילה בחצות.

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

אוטומציה בסיסית עם סקריפטים של Bash: צעדים ראשונים

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

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

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

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

עם תרגול, תבנו בסופו של דבר "ספרייה אישית" קטנה של סקריפטים שיהפכו לעוזרים השקטים שלכם, מוכנים לפעול בכוחות עצמם הודות לטיימרים של cron, at או systemd.

אוטומציה ואבטחה: חיזוק שרת לינוקס

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

בלוק מפתח ראשון הוא ניהול חשבון משתמשמומלץ להימנע משמות משתמש גנריים או ברורים (כגון "admin" או "oracle"), להשתמש בשמות פחות צפויים, לקבוע מדיניות סיסמאות חזקה עם תפוגה תקופתית, ולהתאים טווחי UID כך שלא יהיה קל לניחוש.

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

עליך גם לבדוק שירותים הפועלים באמצעות כלים כמו systemctl, לעצור ולהשבית את אלה שאינם תורמים דבר, ו בדוק את פורטי ההאזנה באמצעות כלי עזר כמו netstat או ss כדי להבטיח שרק אלו ההכרחיים ביותר יהיו פתוחים.

אם נוסיף הקשחה טובה של SSH (השבתת כניסה ישירה ל-root, שימוש באימות מפתח, התאמת פסקי זמן) ושימוש בחומות אש כמו firewalld או iptables, אנו מקבלים מספר שכבות של הגנה מפני התקפות חיצוניות בלי יותר מדי סיבוך.

SELinux, חומות אש ואופטימיזציה עם מכוון

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

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

בהקשר של הרשת, firewalld או iptables הם מאפשרים לך להגדיר כללים מפורטים לגבי תעבורה נכנסת ויוצאת.על ידי פתיחת שירותים ספציפיים בלבד כגון SSH, HTTP, או כל דבר אחר שבאמת נחוץ. זה מפחית מאוד את מספר וקטורי התקיפה הפוטנציאליים.

מצד שני, ישנם כלים כמו מכוון, מיועד ל למטב את ביצועי המערכת שימוש בפרופילים מוגדרים מראש המבוססים על סוג עומס העבודה: שרת, שולחן עבודה, אורחים וירטואליים וכו'. הפעלת הפרופיל המתאים ומתן אפשרות לנהל פרמטרים מסוימים על ידי Tuned חוסכת זמן ומשפרת את הביצועים הכוללים.

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

Ansible: אוטומציה בקנה מידה גדול וניהול תצורה

כשעוברים משרת אחד או שניים לעשרות או מאות, cron וסקריפטים מקומיים לוקים בחסר בשמירה על עקביות. Ansible נכנסת לתמונה ככלי אוטומציה וניהול תצורה זה לא דורש סוכנים על הצמתים, ומסתמך על SSH וקבצי YAML קריאים.

בעזרת Ansible ניתן להגדיר רשימות מלאי של מארחים, ליצור זוגות מפתחות SSH לאימות ללא סיסמה, ולהפוך את ה... ניהול מערכת לינוקס כתיבה ספרי משחק המתארים את המצב הרצוי של השרתיםאילו חבילות יש להתקין, אילו שירותים צריכים להיות פעילים, אילו קבצי תצורה צריכים להיות נוכחים וכו'.

היתרון הגדול הוא שניתן ליישם את אותו ספר משחקים על מערכות רבות בו זמנית, כדי להשיג תוצאה עקבית וניתנת לחזרהקשה מאוד להשיג זאת אם כל מנהל יחיל שינויים באופן ידני. יתר על כן, Ansible הוא אידמפוטנטי: הפעלת אותו ספר משחקים מספר פעמים לא פוגעת בשום דבר; הוא פשוט מבטיח שהכל יהיה כפי שהוא אמור להיות.

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

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

אוטומציה יומיומית: דוגמאות ופילוסופיית עבודה

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

יש אנשים שאפילו רואים במסוף עוזר שקט שעושה דברים בשבילכם ברקע: תזמון תזכורות בדוא"ל, יצירת סיכומים שבועיים, סנכרון ספריות עם שרתים מרוחקים, או... ניקוי תיקיות הורדה וזמניות מבלי להרים אצבע.

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

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

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

על ידי שילוב כל החלקים הללו - סקריפטים של Bash, cron, anacron, at, טיימרים של systemd, Ansible, שיטות עבודה מומלצות לאבטחה, חומות אש וכלי אופטימיזציה - בסופו של דבר אתם בונים סביבה שבה לינוקס עובדת בשבילכם 24/7, מתחזקת גיבויים, מחזקת את האבטחה ודואגת לביצועים., בזמן שאתה מקדיש את עצמך לבעיות פחות מכניות ויותר מעניינות.