תצורת פרויקט בתוך ומחוץ Kubernetes

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

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

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

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

Dict[str, Dict[str, Union[str, int, float]]]

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

adminka:
  django_secret: "ExtraLongAndHardCode"

db_main:
  engine: mysql
  host: 256.128.64.32
  user: cool_user
  password: "SuperHardPassword"

redis:
  host: 256.128.64.32
  pw: "SuperHardPassword"
  port: 26379

smtp:
  server: smtp.gmail.com
  port: 465
  email: [email protected]
  pw: "SuperHardPassword"

במקביל, השדה engine ניתן להתקין מסדי נתונים על SQLite, ו redis מכוון ל mock, ציון גם את שם הקובץ לשמירה - פרמטרים אלה מזוהים ומעובדים בצורה נכונה, מה שמקל על הפעלת הקוד מקומית לצורך איתור באגים, בדיקת יחידות וכל צורך אחר. זה חשוב לנו במיוחד מכיוון שיש עוד הרבה צרכים - חלק מהקוד שלנו מיועד לחישובים אנליטיים שונים, הוא פועל לא רק על שרתים עם תזמור, אלא גם עם סקריפטים שונים, ועל מחשבים של אנליסטים שצריכים לעבוד דרך וניפוי באגים בצינורות עיבוד נתונים מורכבים מבלי להדאיג בעיות קצה. אגב, לא יזיק לשתף שהכלים העיקריים שלנו, כולל קוד פריסת התצורה, מותקנים באמצעות setup.py - ביחד זה מאחד את הקוד שלנו לאקוסיסטם אחד, ללא תלות בפלטפורמה ובשיטת השימוש.

התיאור של תרמיל Kubernetes נראה כך:

containers:
  - name : enter-api
    image: enter-api:latest
    ports:
      - containerPort: 80
    volumeMounts:
      - name: db-main-secret-volume
        mountPath: /etc/secrets/db-main

volumes:
  - name: db-main-secret-volume
    secret:
      secretName: db-main-secret

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

apiVersion: v1
kind: Secret
metadata:
  name: db-main-secret
type: Opaque
stringData:
  db_main.yaml: |
    engine: sqlite
    filename: main.sqlite3

יחד זה מביא ליצירת קבצי YAML לאורך הנתיב /etc/secrets/db-main/section_name.yaml

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

config.py

__author__ = 'AivanF'
__copyright__ = 'Copyright 2020, AivanF'

import os
import yaml

__all__ = ['config']
PROJECT_DIR = os.path.abspath(__file__ + 3 * '/..')
SECRETS_DIR = '/etc/secrets'
KEY_LOG = '_config_log'
KEY_DBG = 'debug'

def is_yes(value):
    if isinstance(value, str):
        value = value.lower()
        if value in ('1', 'on', 'yes', 'true'):
            return True
    else:
        if value in (1, True):
            return True
    return False

def update_config_part(config, key, data):
    if key not in config:
        config[key] = data
    else:
        config[key].update(data)

def parse_big_config(config, filename):
    '''
    Parse YAML config with multiple section
    '''
    if not os.path.isfile(filename):
        return False
    with open(filename) as f:
        config_new = yaml.safe_load(f.read())
        for key, data in config_new.items():
            update_config_part(config, key, data)
        config[KEY_LOG].append(filename)
        return True

def parse_tiny_config(config, key, filename):
    '''
    Parse YAML config with a single section
    '''
    with open(filename) as f:
        config_tiny = yaml.safe_load(f.read())
        update_config_part(config, key, config_tiny)
        config[KEY_LOG].append(filename)

def combine_config():
    config = {
        # To debug config load code
        KEY_LOG: [],
        # To debug other code
        KEY_DBG: is_yes(os.environ.get('DEBUG')),
    }
    # For simple local runs
    CONFIG_SIMPLE = os.path.join(PROJECT_DIR, 'config.yaml')
    parse_big_config(config, CONFIG_SIMPLE)
    # For container's tests
    CONFIG_ENVVAR = os.environ.get('CONFIG')
    if CONFIG_ENVVAR is not None:
        if not parse_big_config(config, CONFIG_ENVVAR):
            raise ValueError(
                f'No config file from EnvVar:n'
                f'{CONFIG_ENVVAR}'
            )
    # For K8s secrets
    for path, dirs, files in os.walk(SECRETS_DIR):
        depth = path[len(SECRETS_DIR):].count(os.sep)
        if depth > 1:
            continue
        for file in files:
            if file.endswith('.yaml'):
                filename = os.path.join(path, file)
                key = file.rsplit('.', 1)[0]
                parse_tiny_config(config, key, filename)
    return config

def build_config():
    config = combine_config()
    # Preprocess
    for key, data in config.items():
        if key.startswith('db_'):
            if data['engine'] == 'sqlite':
                data['filename'] = os.path.join(PROJECT_DIR, data['filename'])
    # To verify correctness
    if config[KEY_DBG]:
        print(f'** Loaded config:n{yaml.dump(config)}')
    else:
        print(f'** Loaded config from: {config[KEY_LOG]}')
    return config

config = build_config()

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

אני מקווה שמה שמתואר יהיה שימושי למישהו :) כל הערה והמלצה לגבי אבטחה או תחומים אחרים לשיפור מתקבלות. גם דעת הקהילה מעניינת, אולי כדאי להוסיף תמיכה ב-ConfigMaps (הפרויקט שלנו עדיין לא משתמש בהם) ולפרסם את הקוד ב-GitHub / PyPI? באופן אישי, אני חושב שדברים כאלה אינדיבידואליים מכדי שפרויקטים יהיו אוניברסליים, וקצת הצצה ליישום של אנשים אחרים, כמו זה שניתן כאן, ודיון בניואנסים, טיפים ושיטות עבודה מומלצות, שאני מקווה לראות בתגובות. , זה מספיק 😉

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.

האם עלי לפרסם כפרויקט/ספרייה?

• 0,0%כן, הייתי משתמש ב-/contribution0

• 33,3%כן, זה נשמע נהדר4

• 41,7%לא, מי צריך לעשות את זה בעצמו במתכונת שלו ובהתאם לצרכיו5

• 25,0%אני אמנע מלענות 3

12 משתמשים הצביעו. 3 משתמשים נמנעו.

מקור: www.habr.com