Конфигурација на проектот внатре и надвор од Kubernetes

Неодамна напишав одговор за животниот век на проектот во Docker и кодот за дебагирање надвор од него, каде што накратко спомна дека можете да направите сопствен конфигурациски систем за услугата да работи добро во Kuber, да открива тајни и да работи погодно локално, дури и надвор од Docker целосно. Ништо комплицирано, но опишаниот „рецепт“ може да биде корисен за некого :) Кодот е во Python, но логиката не е поврзана со јазикот.

Позадината на прашањето е ова: некогаш постоеше еден проект, во почетокот тоа беше мал монолит со комунални услуги и скрипти, но со текот на времето растеше, поделен на услуги, кои пак почнаа да се делат на микросервиси и потоа се зголеми. Отпрвин, сето ова беше направено на голи VPS, процесите на поставување и распоредување на кодот на кој беа автоматизирани со помош на Ansible, а секоја услуга беше компајлирана со конфигурација YAML со потребните поставки и клучеви, а слична конфигурациска датотека беше искористена за локални лансирања, што беше многу погодно, бидејќи .k оваа конфигурација е вчитана во глобален објект, достапен од каде било во проектот.

Сепак, растот на бројот на микросервиси, нивните врски и потреба од централизирано сеча и следење, навестуваше преселба во Кубер, која се уште е во тек. Заедно со помош во решавањето на споменатите проблеми, Kubernetes ги нуди своите пристапи за управување со инфраструктурата, вклучително и таканаречени Тајни и начини да се работи со нив. Механизмот е стандарден и сигурен, така што буквално е грев да не се користи! Но, во исто време, би сакал да го задржам мојот сегашен формат за работа со конфигурацијата: прво, да го користам подеднакво во различни микросервиси на проектот, и второ, да можам да го стартувам кодот на локалната машина користејќи една едноставна конфигурациска датотека.

Во овој поглед, механизмот за конструирање на конфигурациски објект беше изменет за да може да работи и со нашата класична конфигурациска датотека и со тајните од Kuber. Беше наведена и поригидна конфигурациска структура, на јазикот на третиот Python, како што следува:

Дикт[улица, Дикт[улица, Унија[ул, инт, плови]]]

Односно, конечниот когфиг е речник со именувани делови, од кои секоја е речник со вредности од едноставни типови. И деловите ја опишуваат конфигурацијата и пристапот до ресурсите од одреден тип. Пример за дел од нашата конфигурација:

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 – заедно ова го обединува нашиот код во единствен екосистем, независен од платформата и начинот на користење.

Описот на подлогата на Кубернетес изгледа вака:

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()

Логиката овде е прилично едноставна: комбинираме големи конфигурации од директориумот на проектот и патеки по променлива на околината и мали конфигурациски секции од тајните на Кубер, а потоа малку ги обработуваме однапред. Плус некои променливи. Забележувам дека при пребарување на датотеки од тајни, се користи ограничување на длабочината, бидејќи K8s создава скриена папка во секоја тајна каде што се чуваат самите тајни, а само врската се наоѓа на повисоко ниво.

Се надевам дека опишаното ќе биде корисно за некого :) Прифатени се сите коментари и препораки во врска со безбедноста или други области за подобрување. Мислењето на заедницата е исто така интересно, можеби вреди да се додаде поддршка за ConfigMaps (нашиот проект сè уште не ги користи) и да го објавиме кодот на GitHub / PyPI? Лично мислам дека таквите работи се премногу индивидуални за проектите да бидат универзални, и малку да се ѕирнат туѓи имплементации, како оваа дадена овде, и дискусија за нијанси, совети и најдобри практики, кои се надевам дека ќе ги видам во коментарите , доволно е 😉

Само регистрирани корисници можат да учествуваат во анкетата. Најави се, вие сте добредојдени.

Дали треба да објавувам како проект/библиотека?

• 0,0%Да, би користел /contribution0

• 33,3%Да, тоа звучи одлично4

• 41,7%Не, кој треба да го направи тоа сам во свој формат и да одговара на нивните потреби5

• 25,0%Ќе се воздржам од одговор3

Гласаа 12 корисници. 3 корисници се воздржаа.

Извор: www.habr.com