Projektkonfiguration inuti och utanför Kubernetes

Nyligen skrev jag ett svar om projektets liv i Docker och felsökning av kod utanför det, där jag kort nämnde att man kan skapa sitt eget konfigurationssystem för att tjänsten även ska fungera bra i Kubernetes, hämta hemligheter och köras bekvämt lokalt, även helt utanför Docker. Inget komplicerat, men det beskrivna "receptet" kan vara till nytta för någon 🙂 Koden är skriven i Python, men logiken är inte knuten till språket.

Bakgrunden till frågan är följande: det fanns ett projekt som först var en liten monolit med verktyg och skript, men med tiden växte det, delades upp i tjänster, som i sin tur delades upp i mikrotjänster och sedan även skalades. Initialt kördes allt detta på rena VPS:er, där processen att konfigurera och distribuera koden automatiserades med hjälp av Ansible och varje tjänst fick en YAML-konfiguration med nödvändiga inställningar och nycklar, och en liknande konfigurationsfil användes för lokala körningar, vilket var mycket praktiskt, eftersom denna konfig laddas in i ett globalt objekt som är tillgängligt från vilken plats som helst inom projektet.

Men antalet mikrotjänster, deras kopplingar och behovet av centraliserad loggning och övervakning, förutsade en flytt till Kubernetes, som fortfarande är under process. Tillsammans med hjälp med att lösa ovan nämnda uppgifter, erbjuder Kubernetes sina metoder för infrastrukturhantering, inklusive så kallade hemligheter och metoder för att arbeta med dem. Mekanismen är standardiserad och pålitlig, så det är bokstavligen synd att inte dra nytta av den! Men samtidigt ville jag behålla vårt nuvarande arbetssätt med konfigurationen: för det första, enhetligt använda den i olika mikrotjänster i projektet, och för det andra, ha möjlighet att köra koden på den lokala maskinen med hjälp av en enkel konfigurationsfil.

I samband med detta har mekanismen för att bygga konfigurationsobjekt utvecklats så att den kan arbeta både med vår klassiska konfigurationsfil och med hemligheterna från Kubernetes. En striktare struktur för konfigurationen har också definierats, på det tredje Python-språket, så här:

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

Det vill säga, den slutgiltiga konfigurationen är en ordbok med namngivna sektioner, där varje del är en ordbok med värden av enkla typer. Sektionerna beskriver konfigurationen och tillgångarna till resurser av en viss typ. Ett exempel på en del av vår konfiguration:

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: info@test.com
  pw: "SuperHardPassword"

Samtidigt, fältet engine databasen kan sättas till SQLite, medan redis konfigureras till mock, med ett filnamn för lagring angivet – dessa parametrar känns igen och bearbetas korrekt, vilket gör det enkelt att köra koden lokalt för felsökning, enhetstestning och andra behov. Detta är särskilt aktuellt för oss, eftersom vi har många sådana behov – en del av vår kod är avsedd för olika analytiska beräkningar, och körs inte bara på servrar med orkestrering, utan även av olika skript och på analytikers datorer som behöver arbeta igenom och felsöka komplexa databehandlingskedjor utan att bekymra sig om backend-frågor. Förresten, det vore bra att nämna att våra huvudverktyg, inklusive koden för att sätta ihop konfigurationen, installeras via setup.py – tillsammans sammanfogar detta vår kod till ett sammanhängande ekosystem, oberoende av plattform och användningsmetod.

Beskrivningen av podden i Kubernetes ser ut så här:

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

Det betyder att varje hemlighet beskriver en sektion. Själva hemligheterna skapas så här:

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

Tillsammans leder detta till skapandet av YAML-filer på vägen /etc/secrets/db-main/section_name.yaml

Och för lokala körningar används en konfiguration som finns i projektets rotmapp eller på sökvägen angiven i miljövariabeln. Koden som ansvarar för dessa bekvämligheter kan ses i spoilern.

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

Logiken här är ganska enkel: vi slår ihop stora konfigurationer från projektmappen och sökvägen genom miljövariabeln, och små konfigurationer-sektioner från K8s-hemligheter, och bearbetar dem sedan lite. Plus några variabler. Jag noterar att det finns en djupbegränsning vid sökning av filer från hemligheter, eftersom K8s skapar ytterligare en dold mapp i varje hemlighet där själva hemligheterna lagras, och en nivå ovanför finns bara en länk.

Jag hoppas att det jag beskriver kommer att vara till nytta för någon 🙂 Alla kommentarer och rekommendationer kring säkerhet eller andra förbättringar tas emot. Det skulle också vara intressant att höra vad samhälle tycker, kanske borde vi lägga till stöd för ConfigMaps (de används inte i vårt projekt än) och publicera koden på GitHub / PyPI? Personligen tror jag att sådana saker är för individuella för projekt för att vara universella, och det räcker med lite insyn i andras implementeringar, som den som presenteras här, och att diskutera detaljer, råd och bästa metoder som jag hoppas få se i kommentarerna 😉

Endast registrerade användare kan delta i omröstningen. Logga in, tack.

Bör vi publicera det som ett projekt/bibliotek?

• 0,0%Ja, jag skulle använda / bidra

• 33,3%Ja, det låter bra

• 41,7%Nej, de som behöver det gör det själva i sitt format och för sina behov

• 25,0%Jag avstår från att svara

12 användare röstade. 3 användare avstod.

Källa: habr.com