אם תשתית ה-IT שלך גדלה מהר מדי, במוקדם או במאוחר תעמוד בפני בחירה: להגדיל באופן ליניארי את משאבי האנוש כדי לתמוך בה או להתחיל אוטומציה. עד לשלב מסוים, חיינו בפרדיגמה הראשונה, ואז התחילה הדרך הארוכה לתשתית-כקוד.
כמובן ש-NSPK הוא לא סטארטאפ, אבל אווירה כזו שלטה בחברה בשנים הראשונות לקיומה, ואלו היו שנים מאוד מעניינות. שמי , אני תומך בתשתית לינוקס עם דרישות זמינות גבוהות כבר למעלה מ-10 שנים. הוא הצטרף לצוות NSPK בינואר 2016 ולמרבה הצער, לא ראה את תחילת קיומה של החברה, אבל הגיע בשלב של שינויים גדולים.
באופן כללי, ניתן לומר שהצוות שלנו מספק 2 מוצרים עבור החברה. הראשון הוא תשתיות. דואר אמור לעבוד, DNS אמור לעבוד, ובקרי תחום צריכים להכניס אותך לשרתים שלא אמורים לקרוס. נוף ה-IT של החברה עצום! אלו הן מערכות קריטיות לעסקים ולמשימה, דרישות הזמינות עבור חלקן הן 99,999. המוצר השני הוא השרתים עצמם, פיזיים ווירטואליים. יש לפקח על הקיימים, וחדשים חייבים להיות מועברים באופן קבוע ללקוחות ממחלקות רבות. במאמר זה אני רוצה להתמקד כיצד פיתחנו את התשתית שאחראית על מחזור חיי השרת.
תחילתו של מסע
בתחילת דרכנו, ערימת הטכנולוגיה שלנו נראתה כך:
מערכת הפעלה CentOS 7
בקרי דומיין FreeIPA
אוטומציה - Ansible(+Tower), Cobbler
כל זה היה ממוקם ב-3 תחומים, הפרוסים על פני מספר מרכזי נתונים. במרכז נתונים אחד יש מערכות משרדיות ואתרי בדיקה, בשאר יש PROD.
יצירת שרתים בשלב מסוים נראתה כך:
בתבנית VM, CentOS הוא מינימלי והמינימום הנדרש הוא כמו /etc/resolv.conf הנכון, השאר מגיע דרך Ansible.
CMDB - אקסל.
אם השרת הוא פיזי, אז במקום להעתיק את המחשב הוירטואלי, מערכת ההפעלה הותקנה עליו באמצעות Cobbler - כתובות ה-MAC של שרת היעד מתווספות לתצורת Cobbler, השרת מקבל כתובת IP דרך DHCP, ולאחר מכן מערכת ההפעלה נוסף.
בהתחלה אפילו ניסינו לעשות סוג של ניהול תצורה ב- Cobbler. אבל עם הזמן, זה התחיל להביא בעיות בניידות של תצורות הן למרכזי נתונים אחרים והן לקוד Ansible להכנת מחשבי VM.
באותה תקופה, רבים מאיתנו תפסו את Ansible כהרחבה נוחה של Bash ולא חסכו בעיצובים באמצעות shell ו-sed. בסך הכל Bashsible. זה הוביל בסופו של דבר לעובדה שאם ה-Playbook מסיבה כלשהי לא עבד על השרת, היה קל יותר למחוק את השרת, לתקן את ה-Playbook ולהפעיל אותו שוב. למעשה לא היה ניהול גרסאות של סקריפטים, לא ניידות של תצורות.
לדוגמה, רצינו לשנות תצורה כלשהי בכל השרתים:
- אנו משנים את התצורה בשרתים קיימים בסגמנט הלוגי/דאטה סנטר. לפעמים לא ביום אחד - דרישות הנגישות וחוק המספרים הגדולים לא מאפשרים להחיל את כל השינויים בבת אחת. וכמה שינויים עלולים להיות הרסניים ודורשים הפעלה מחדש של משהו - משירותים ועד מערכת ההפעלה עצמה.
- מתקן את זה ב-Ansible
- אנחנו מתקנים את זה בסנדלר
- חזור על N פעמים עבור כל קטע לוגי/מרכז נתונים
כדי שכל השינויים יעברו בצורה חלקה, היה צורך לקחת בחשבון גורמים רבים, והשינויים מתרחשים ללא הרף.
- שחזור קוד אפשרי, קבצי תצורה
- שינוי שיטות עבודה מומלצות פנימיות
- שינויים על בסיס תוצאות ניתוח תקריות/תאונות
- שינוי תקני אבטחה, פנימיים וחיצוניים. לדוגמה, PCI DSS מתעדכן בדרישות חדשות מדי שנה
גידול תשתיות ותחילת הדרך
גדל מספר השרתים/דומיינים לוגיים/דאטה סנטרים ואיתם מספר השגיאות בתצורות. בשלב מסוים, הגענו לשלושה כיוונים שבהם צריך לפתח ניהול תצורה:
- אוטומציה. יש להימנע ככל האפשר מטעויות אנוש בפעולות חוזרות ונשנות.
- הֲדִירוּת. הרבה יותר קל לנהל תשתית כשהיא צפויה. תצורת השרתים והכלים להכנתם צריכה להיות זהה בכל מקום. זה חשוב גם עבור צוותי מוצר - לאחר בדיקה, יש להבטיח שהאפליקציה תגיע לסביבת ייצור המוגדרת באופן דומה לסביבת הבדיקה.
- פשטות ושקיפות של ביצוע שינויים בניהול התצורה.
נותר להוסיף כמה כלים.
בחרנו ב-GitLab CE כמאגר הקוד שלנו, לא מעט בגלל מודולי ה-CI/CD המובנים שלו.
כספת הסודות - כספת Hashicorp, כולל. עבור ה-API הנהדר.
בדיקת תצורות ותפקידים אפשריים - מולקולה+טסטינפרה. הבדיקות עוברות הרבה יותר מהר אם מתחברים למיטוגן אפשרי. במקביל, התחלנו לכתוב CMDB ותזמור משלנו לפריסה אוטומטית (בתמונה למעלה Cobbler), אבל זה סיפור אחר לגמרי, שעמיתי והמפתח הראשי של המערכות הללו יספרו בעתיד.
הבחירה שלנו:
מולקולה + טסטינפרה
Ansible + Tower + AWX
עולם השרתים + DITNET (פיתוח עצמי)
סַנדְלָר
רץ Gitlab + GitLab
כספת השיקורפ
אגב, לגבי תפקידים אפשריים. בהתחלה היה רק אחד, אבל אחרי כמה עיבודים מחדש היו 17 מהם. אני ממליץ בחום לחלק את המונוליט לתפקידים חסרי כוח, שאותם ניתן להפעיל בנפרד; בנוסף, אתה יכול להוסיף תגיות. חילקנו את התפקידים לפי פונקציונליות - רשת, רישום, חבילות, חומרה, מולקולה וכו'. באופן כללי, עקבנו אחר האסטרטגיה שלהלן. אני לא מתעקש שזו האמת היחידה, אבל זה עבד בשבילנו.
- העתקת שרתים מ"תמונת הזהב" היא רעה!החיסרון העיקרי הוא שאתה לא יודע בדיוק באיזה מצב התמונות נמצאות עכשיו, ושכל השינויים יגיעו לכל התמונות בכל חוות הוירטואליזציה.
- השתמש בקובצי תצורת ברירת המחדל למינימום והסכים עם מחלקות אחרות שאתה אחראי על קבצי המערכת הראשיים, לדוגמה:
- השאר את /etc/sysctl.conf ריק, ההגדרות צריכות להיות רק ב- /etc/sysctl.d/. ברירת המחדל שלך בקובץ אחד, מותאמת אישית ליישום בקובץ אחר.
- השתמש בקבצי עקיפה כדי לערוך יחידות מערכת.
- עצב את כל ההגדרות וכלול אותן במלואן; אם אפשר, אין סד או אנלוגים שלו בספרי משחק
- שחזור קוד מערכת ניהול התצורה:
- חלק את המשימות ליישויות הגיוניות ושכתב את המונוליט לתפקידים
- השתמש בליטרים! Ansible-lint, yaml-lint וכו'
- שנה את הגישה שלך! לא מביך. יש צורך לתאר את מצב המערכת
- עבור כל תפקידי Ansible אתה צריך לכתוב מבחנים במולקולה ולהפיק דוחות פעם ביום.
- בענייננו, לאחר הכנת הבדיקות (מהן יותר מ-100) נמצאו כ-70000 טעויות. לקח כמה חודשים לתקן את זה.
היישום שלנו
אז, התפקידים האפשריים היו מוכנים, מעוצבים ונבדקו על ידי אופניים. ואפילו גיטים מועלים בכל מקום. אבל השאלה של מסירת קוד אמינה למקטעים שונים נותרה פתוחה. החלטנו לסנכרן עם סקריפטים. נראה כך:
לאחר שהשינוי מגיע, CI מופעל, שרת בדיקה נוצר, תפקידים מתגלגלים ונבדקים על ידי המולקולה. אם הכל בסדר, הקוד עובר לסניף ה-prod. אבל אנחנו לא מיישמים קוד חדש על שרתים קיימים במכונה. זהו מעין פקק הכרחי לזמינות גבוהה של המערכות שלנו. וכשהתשתית הופכת לעצומה, נכנס לתמונה חוק המספרים הגדולים - גם אם אתה בטוח שהשינוי אינו מזיק, הוא עלול להוביל לתוצאות קשות.
ישנן גם אפשרויות רבות ליצירת שרתים. בסופו של דבר בחרנו סקריפטים מותאמים אישית של Python. ולגבי CI ansible:
- name: create1.yml - Create a VM from a template
vmware_guest:
hostname: "{{datacenter}}".domain.ru
username: "{{ username_vc }}"
password: "{{ password_vc }}"
validate_certs: no
cluster: "{{cluster}}"
datacenter: "{{datacenter}}"
name: "{{ name }}"
state: poweredon
folder: "/{{folder}}"
template: "{{template}}"
customization:
hostname: "{{ name }}"
domain: domain.ru
dns_servers:
- "{{ ipa1_dns }}"
- "{{ ipa2_dns }}"
networks:
- name: "{{ network }}"
type: static
ip: "{{ip}}"
netmask: "{{netmask}}"
gateway: "{{gateway}}"
wake_on_lan: True
start_connected: True
allow_guest_control: True
wait_for_ip_address: yes
disk:
- size_gb: 1
type: thin
datastore: "{{datastore}}"
- size_gb: 20
type: thin
datastore: "{{datastore}}"לזה הגענו, המערכת ממשיכה לחיות ולהתפתח.
- 17 תפקידים סבירים להקמת שרת. כל אחד מהתפקידים נועד לפתור משימה לוגית נפרדת (רישום, ביקורת, הרשאת משתמש, ניטור וכו').
- בדיקת תפקידים. מולקולה + TestInfra.
- פיתוח עצמי: CMDB + תזמורת.
- זמן יצירת השרת הוא ~30 דקות, אוטומטי ובלתי תלוי כמעט בתור המשימות.
- אותו מצב/שם התשתית בכל הסגמנטים - ספרי משחק, מאגרים, אלמנטים וירטואליזציה.
- בדיקה יומית של מצב השרת עם הפקת דוחות על אי התאמה לתקן.
אני מקווה שהסיפור שלי יהיה שימושי למי שנמצא בתחילת דרכם. באיזה מחסנית אוטומציה אתה משתמש?
מקור: www.habr.com