პროექტის კონფიგურაცია Kubernetes-ის შიგნით და გარეთ

ცოტა ხნის წინ დავწერე პასუხი Docker-ში პროექტის სიცოცხლისა და მის გარეთ კოდის გამართვის შესახებ, სადაც მან მოკლედ აღნიშნა, რომ თქვენ შეგიძლიათ შექმნათ თქვენი საკუთარი კონფიგურაციის სისტემა ისე, რომ სერვისმა კარგად იმუშაოს Kuber-ში, ამოიღოს საიდუმლოებები და მოხერხებულად იმუშაოს ადგილობრივად, თუნდაც Docker-ის გარეთ. არაფერი რთული, მაგრამ აღწერილი „რეცეპტი“ შეიძლება ვინმეს გამოადგეს :) კოდი არის პითონში, მაგრამ ლოგიკა ენაზე არ არის მიბმული.

კითხვის საფუძველი ასეთია: ოდესღაც იყო ერთი პროექტი, თავიდან ეს იყო პატარა მონოლითი კომუნალური და სკრიპტებით, მაგრამ დროთა განმავლობაში ის გაიზარდა, დაყოფილი იყო სერვისებად, რომელიც თავის მხრივ დაიწყო მიკროსერვისებად დაყოფა და შემდეგ მასშტაბური. თავდაპირველად, ეს ყველაფერი გაკეთდა შიშველ VPS-ზე, კოდის დაყენებისა და განლაგების პროცესები, რომლებზედაც ავტომატიზირებული იყო Ansible-ის გამოყენებით და თითოეული სერვისი შედგენილი იყო YAML კონფიგურაციით, საჭირო პარამეტრებით და გასაღებებით, და გამოყენებული იყო მსგავსი კონფიგურაციის ფაილი. ლოკალური გაშვება, რაც ძალიან მოსახერხებელი იყო, რადგან .k ეს კონფიგურაცია იტვირთება გლობალურ ობიექტში, რომელიც ხელმისაწვდომია პროექტის ნებისმიერი ადგილიდან.

თუმცა, მიკროსერვისების რაოდენობის ზრდა, მათი კავშირები და საჭიროა ცენტრალიზებული ხე-ტყის აღრიცხვა და მონიტორინგი, უწინასწარმეტყველა კუბერში გადასვლა, რომელიც ჯერ კიდევ მიმდინარეობს. აღნიშნული პრობლემების გადაჭრაში დახმარებასთან ერთად, Kubernetes გთავაზობთ ინფრასტრუქტურის მართვის თავის მიდგომებს, მათ შორის საიდუმლოებები и მათთან მუშაობის გზები. მექანიზმი სტანდარტული და საიმედოა, ამიტომ მისი არ გამოყენება ფაქტიურად ცოდვაა! მაგრამ ამავდროულად, მსურს შევინარჩუნო ჩემი მიმდინარე ფორმატი კონფიგურაციასთან მუშაობისთვის: ჯერ ერთი, ერთნაირად გამოვიყენო იგი პროექტის სხვადასხვა მიკროსერვისში და მეორეც, შევძლო კოდის გაშვება ადგილობრივ აპარატზე ერთი მარტივი გამოყენებით. კონფიგურაციის ფაილი.

ამასთან დაკავშირებით, შეიცვალა კონფიგურაციის ობიექტის აგების მექანიზმი, რათა შესაძლებელი ყოფილიყო მუშაობა როგორც ჩვენს კლასიკურ კონფიგურაციის ფაილთან, ასევე Kuber-ის საიდუმლოებებთან. უფრო ხისტი კონფიგურაციის სტრუქტურა ასევე მითითებული იყო მესამე პითონის ენაზე, შემდეგნაირად:

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

ანუ, საბოლოო cogfig არის ლექსიკონი დასახელებული სექციებით, რომელთაგან თითოეული არის ლექსიკონი მარტივი ტიპებიდან მნიშვნელობებით. და სექციები აღწერს კონფიგურაციას და წვდომას გარკვეული ტიპის რესურსებზე. ჩვენი კონფიგურაციის ნაწილის მაგალითი:

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 pod-ის აღწერა ასე გამოიყურება:

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

და ადგილობრივი გაშვებისთვის, კონფიგურაცია გამოიყენება, რომელიც მდებარეობს პროექტის root დირექტორიაში ან გარემოს ცვლადში მითითებული ბილიკის გასწვრივ. ამ მოხერხებულობაზე პასუხისმგებელი კოდი შეგიძლიათ იხილოთ სპოილერში.

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