ការកំណត់រចនាសម្ព័ន្ធគម្រោងខាងក្នុង និងខាងក្រៅ Kubernetes

ថ្មីៗនេះខ្ញុំបានសរសេរ ឆ្លើយអំពីជីវិតគម្រោងនៅក្នុង Docker និងការបំបាត់កំហុសនៅខាងក្រៅវា។ដែលជាកន្លែងដែលគាត់បាននិយាយយ៉ាងខ្លីថា អ្នកអាចបង្កើតប្រព័ន្ធកំណត់រចនាសម្ព័ន្ធផ្ទាល់ខ្លួនរបស់អ្នក ដើម្បីឱ្យសេវាកម្មដំណើរការបានល្អនៅក្នុង Kuber ទាញអាថ៌កំបាំង និងដំណើរការយ៉ាងងាយស្រួលក្នុងមូលដ្ឋាន សូម្បីតែនៅខាងក្រៅ Docker ក៏ដោយ។ គ្មានអ្វីស្មុគស្មាញទេ ប៉ុន្តែ "រូបមន្ត" ដែលបានពិពណ៌នាអាចមានប្រយោជន៍សម្រាប់នរណាម្នាក់ :) កូដគឺនៅក្នុង Python ប៉ុន្តែតក្កវិជ្ជាមិនជាប់នឹងភាសាទេ។

សាវតានៃសំណួរគឺនេះ៖ យូរៗម្តងមានគម្រោងមួយ ដែលដំបូងឡើយវាជា monolith តូចមួយដែលមានឧបករណ៍ប្រើប្រាស់ និងស្គ្រីប ប៉ុន្តែយូរៗទៅវាបានរីកធំឡើង បែងចែកជាសេវាកម្ម ដែលនៅក្នុងវេនចាប់ផ្តើមបែងចែកទៅជា microservices និង បន្ទាប់មកពង្រីក។ ដំបូង អ្វីៗទាំងអស់នេះត្រូវបានធ្វើនៅលើ VPS ទទេ ដំណើរការនៃការដំឡើង និងការដាក់ពង្រាយកូដដែលដំណើរការដោយស្វ័យប្រវត្តិដោយប្រើ Ansible ហើយសេវាកម្មនីមួយៗត្រូវបានចងក្រងជាមួយការកំណត់រចនាសម្ព័ន្ធ YAML ជាមួយនឹងការកំណត់ និងសោចាំបាច់ ហើយឯកសារកំណត់រចនាសម្ព័ន្ធស្រដៀងគ្នានេះត្រូវបានប្រើសម្រាប់ ការបើកដំណើរការក្នុងស្រុក ដែលងាយស្រួលណាស់ ពីព្រោះ .k ការកំណត់រចនាសម្ព័ន្ធនេះត្រូវបានផ្ទុកទៅក្នុងវត្ថុសកល ដែលអាចចូលប្រើបានពីគ្រប់ទីកន្លែងក្នុងគម្រោង។

ទោះជាយ៉ាងណាក៏ដោយ ការកើនឡើងនៃចំនួនសេវាមីក្រូ ការតភ្ជាប់របស់ពួកគេ និង តម្រូវការសម្រាប់ការកាប់ឈើ និងការត្រួតពិនិត្យកណ្តាលបានបង្ហាញពីការផ្លាស់ប្តូរទៅកាន់ Kuber ដែលកំពុងតែដំណើរការនៅឡើយ។ រួមជាមួយនឹងជំនួយក្នុងការដោះស្រាយបញ្ហាដែលបានលើកឡើង Kubernetes ផ្តល់នូវវិធីសាស្រ្តរបស់ខ្លួនចំពោះការគ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធ រួមទាំង អ្វីដែលគេហៅថាអាថ៌កំបាំង и វិធីធ្វើការជាមួយពួកគេ។. យន្តការ​នេះ​មាន​ស្តង់ដារ និង​អាច​ទុក​ចិត្ត​បាន ដូច្នេះ​វា​ជា​អំពើ​បាប​ដែល​មិន​ត្រូវ​ប្រើ​វា! ប៉ុន្តែនៅពេលជាមួយគ្នានេះ ខ្ញុំចង់រក្សាទម្រង់បច្ចុប្បន្នរបស់ខ្ញុំសម្រាប់ធ្វើការជាមួយការកំណត់៖ ទីមួយ ប្រើវាឱ្យស្មើភាពគ្នាក្នុងសេវាកម្មមីក្រូផ្សេងៗនៃគម្រោង និងទីពីរ ដើម្បីអាចដំណើរការកូដនៅលើម៉ាស៊ីនមូលដ្ឋានដោយប្រើសាមញ្ញមួយ។ ឯកសារកំណត់រចនាសម្ព័ន្ធ។

ក្នុងន័យនេះ យន្តការសម្រាប់ការសាងសង់វត្ថុកំណត់រចនាសម្ព័ន្ធត្រូវបានកែប្រែ ដើម្បីអាចដំណើរការទាំងជាមួយឯកសារកំណត់រចនាសម្ព័ន្ធបុរាណរបស់យើង និងដោយអាថ៌កំបាំងពី Kuber ។ រចនាសម្ព័ន្ធកំណត់រចនាសម្ព័ន្ធរឹងជាងនេះក៏ត្រូវបានបញ្ជាក់ផងដែរ ជាភាសារបស់ Python ទីបីដូចខាងក្រោម៖

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ដោយបញ្ជាក់ផងដែរនូវឈ្មោះឯកសារដែលត្រូវរក្សាទុក - ប៉ារ៉ាម៉ែត្រទាំងនេះត្រូវបានទទួលស្គាល់ និងដំណើរការយ៉ាងត្រឹមត្រូវ ដែលធ្វើឱ្យវាងាយស្រួលក្នុងការដំណើរការកូដក្នុងមូលដ្ឋានសម្រាប់ការកែកំហុស ការធ្វើតេស្តឯកតា និងតម្រូវការផ្សេងៗទៀត។ នេះមានសារៈសំខាន់ជាពិសេសសម្រាប់យើង ពីព្រោះមានតម្រូវការជាច្រើនទៀត - ផ្នែកនៃកូដរបស់យើងត្រូវបានបម្រុងទុកសម្រាប់ការគណនាវិភាគផ្សេងៗ វាដំណើរការមិនត្រឹមតែលើម៉ាស៊ីនមេដែលមានការ orchestration ប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានស្គ្រីបផ្សេងៗ និងនៅលើកុំព្យូទ័ររបស់អ្នកវិភាគដែលត្រូវការធ្វើការតាមរយៈ និងបំបាត់កំហុសបំពង់ដំណើរការទិន្នន័យស្មុគ្រស្មាញដោយមិនបារម្ភពីបញ្ហាផ្នែកខាងក្រោយ។ និយាយអញ្ចឹង វានឹងមិនឈឺចាប់ទេក្នុងការចែករំលែកថាឧបករណ៍សំខាន់ៗរបស់យើង រួមទាំងកូដប្លង់កំណត់ត្រូវបានដំឡើងតាមរយៈ 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

ហើយសម្រាប់ការបើកដំណើរការក្នុងតំបន់ ការកំណត់ត្រូវបានប្រើ ដែលមានទីតាំងនៅក្នុងថតឫសនៃគម្រោង ឬតាមផ្លូវដែលបានបញ្ជាក់នៅក្នុងអថេរបរិស្ថាន។ លេខកូដដែលទទួលខុសត្រូវចំពោះភាពងាយស្រួលទាំងនេះអាចមើលឃើញនៅក្នុង spoiler ។

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 secrets ហើយបន្ទាប់មកដំណើរការពួកវាជាមុនបន្តិច។ បូកអថេរមួយចំនួន។ ខ្ញុំកត់សម្គាល់ថានៅពេលស្វែងរកឯកសារពីអាថ៌កំបាំង ការកំណត់ជម្រៅត្រូវបានប្រើ ពីព្រោះ K8s បង្កើតថតដែលលាក់នៅក្នុងអាថ៌កំបាំងនីមួយៗ ដែលអាថ៌កំបាំងខ្លួនឯងត្រូវបានរក្សាទុក ហើយគ្រាន់តែតំណមួយស្ថិតនៅកម្រិតខ្ពស់ជាង។

ខ្ញុំសង្ឃឹមថាអ្វីដែលបានពិពណ៌នានឹងមានប្រយោជន៍សម្រាប់នរណាម្នាក់ :) រាល់មតិយោបល់ និងអនុសាសន៍ទាក់ទងនឹងសុវត្ថិភាព ឬផ្នែកផ្សេងទៀតសម្រាប់ការកែលម្អត្រូវបានទទួលយក។ មតិរបស់សហគមន៍ក៏គួរឱ្យចាប់អារម្មណ៍ផងដែរ ប្រហែលជាវាមានតម្លៃបន្ថែមការគាំទ្រសម្រាប់ ConfigMaps (គម្រោងរបស់យើងមិនទាន់ប្រើពួកវាទេ) និងការបោះពុម្ពកូដនៅលើ GitHub / PyPI? ដោយផ្ទាល់ ខ្ញុំគិតថារឿងបែបនេះមានលក្ខណៈបុគ្គលពេកសម្រាប់គម្រោងជាសកល ហើយការសម្លឹងមើលការអនុវត្តរបស់អ្នកដ៏ទៃបន្តិច ដូចជាអ្វីដែលបានផ្តល់ឱ្យនៅទីនេះ និងការពិភាក្សាអំពីភាពខុសគ្នា គន្លឹះ និងការអនុវត្តល្អបំផុត ដែលខ្ញុំសង្ឃឹមថានឹងឃើញនៅក្នុងមតិយោបល់ គ្រប់គ្រាន់ហើយ 😉

មានតែអ្នកប្រើប្រាស់ដែលបានចុះឈ្មោះប៉ុណ្ណោះដែលអាចចូលរួមក្នុងការស្ទង់មតិនេះ។ ចូលសូម។

តើខ្ញុំគួរបោះពុម្ពជាគម្រោង/បណ្ណាល័យទេ?

• 0,0%បាទ/ចាស ខ្ញុំនឹងប្រើ /contribution0

• 33,3%បាទ ស្តាប់ទៅល្អណាស់ ៤

• 41,7%ទេ អ្នកណាត្រូវការធ្វើវាដោយខ្លួនឯងតាមទម្រង់របស់ពួកគេ និងសមស្របតាមតម្រូវការរបស់ពួកគេ ៥

• 25,0%ខ្ញុំនឹងបដិសេធមិនឆ្លើយ ៣

អ្នកប្រើប្រាស់ 12 នាក់បានបោះឆ្នោត។ អ្នកប្រើប្រាស់ ៦៣ នាក់ត្រូវបានហាមឃាត់។

ប្រភព: www.habr.com