Kubernetes کے اندر اور باہر پروجیکٹ کی ترتیب

میں نے حال ہی میں لکھا ڈوکر میں پروجیکٹ کی زندگی اور اس سے باہر ڈیبگنگ کوڈ کے بارے میں جواب دیں۔، جہاں اس نے مختصراً ذکر کیا کہ آپ اپنا کنفیگریشن سسٹم بنا سکتے ہیں تاکہ سروس Kuber میں اچھی طرح کام کرے، رازوں کو کھولے، اور مقامی طور پر آسانی سے چل سکے، یہاں تک کہ Docker سے باہر بھی۔ کچھ بھی پیچیدہ نہیں، لیکن بیان کردہ "نسخہ" کسی کے لیے مفید ہو سکتی ہے :) کوڈ ازگر میں ہے، لیکن منطق زبان سے منسلک نہیں ہے۔

سوال کا پس منظر یہ ہے: ایک زمانے میں ایک پروجیکٹ تھا، پہلے تو یہ افادیت اور اسکرپٹ کے ساتھ ایک چھوٹا سا یک سنگی تھا، لیکن وقت کے ساتھ ساتھ یہ بڑھتا گیا، خدمات میں تقسیم ہوتا گیا، جس کے نتیجے میں یہ مائیکرو سروسز میں تقسیم ہونے لگا، اور پھر بڑھا دیا. سب سے پہلے، یہ سب ننگے وی پی ایس پر کیا گیا تھا، کوڈ کو ترتیب دینے اور تعینات کرنے کے عمل کو جوابی استعمال کرتے ہوئے خودکار کیا گیا تھا، اور ہر سروس کو ضروری ترتیبات اور کلیدوں کے ساتھ YAML ترتیب کے ساتھ مرتب کیا گیا تھا، اور اسی طرح کی ایک فائل کا استعمال کیا گیا تھا مقامی لانچ، جو بہت آسان تھا، کیونکہ .k یہ کنفیگریشن ایک عالمی آبجیکٹ میں لوڈ کی گئی ہے، جو پروجیکٹ میں کہیں سے بھی قابل رسائی ہے۔

تاہم، مائیکرو سروسز کی تعداد میں اضافہ، ان کے کنکشن، اور مرکزی لاگنگ اور نگرانی کی ضرورت ہے۔، نے کوبیر کے لیے ایک اقدام کی پیش گوئی کی، جو ابھی تک جاری ہے۔ مذکورہ مسائل کو حل کرنے میں مدد کے ساتھ، Kubernetes بنیادی ڈھانچے کے انتظام کے لیے اپنے نقطہ نظر پیش کرتا ہے، بشمول نام نہاد راز и ان کے ساتھ کام کرنے کے طریقے. طریقہ کار معیاری اور قابل اعتماد ہے، اس لیے اسے استعمال نہ کرنا لفظی طور پر گناہ ہے! لیکن ایک ہی وقت میں، میں کنفیگریشن کے ساتھ کام کرنے کے لیے اپنے موجودہ فارمیٹ کو برقرار رکھنا چاہوں گا: سب سے پہلے، اسے پروجیکٹ کے مختلف مائیکرو سروسز میں یکساں طور پر استعمال کرنا، اور دوسرا، ایک سادہ کا استعمال کرتے ہوئے مقامی مشین پر کوڈ چلانے کے قابل ہونا۔ config فائل.

اس سلسلے میں، کنفیگریشن آبجیکٹ کی تعمیر کے طریقہ کار میں ترمیم کی گئی تھی تاکہ وہ ہماری کلاسک کنفگ فائل کے ساتھ اور کوبیر کے رازوں کے ساتھ کام کر سکے۔ تیسرے ازگر کی زبان میں مزید سخت کنفیگریشن ڈھانچہ بھی بیان کیا گیا تھا، جیسا کہ:

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 پوڈ کی تفصیل اس طرح نظر آتی ہے:

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

یہاں کی منطق کافی آسان ہے: ہم پروجیکٹ ڈائرکٹری سے بڑے کنفیگرز اور پاتھز کو انوائرمنٹ ویری ایبل کے ذریعے، اور کوبیر سیکرٹس سے چھوٹے کنفیگریشن سیکشنز کو یکجا کرتے ہیں، اور پھر ان کو تھوڑا سا پری پروسیس کرتے ہیں۔ علاوہ کچھ متغیرات۔ میں نوٹ کرتا ہوں کہ رازوں سے فائلوں کی تلاش کرتے وقت، گہرائی کی حد استعمال کی جاتی ہے، کیونکہ K8s ہر راز میں ایک پوشیدہ فولڈر بناتا ہے جہاں راز خود محفوظ ہوتے ہیں، اور صرف ایک لنک اعلی سطح پر واقع ہوتا ہے۔

مجھے امید ہے کہ جو بیان کیا گیا ہے وہ کسی کے لیے کارآمد ہو گا :) سیکیورٹی یا بہتری کے لیے دیگر شعبوں کے حوالے سے کوئی بھی تبصرے اور سفارشات قبول کی جائیں گی۔ کمیونٹی کی رائے بھی دلچسپ ہے، شاید یہ ConfigMaps (ہمارا پروجیکٹ انہیں ابھی تک استعمال نہیں کرتا ہے) کے لیے سپورٹ شامل کرنے اور GitHub/PyPI پر کوڈ شائع کرنے کے قابل ہے؟ ذاتی طور پر، میں سمجھتا ہوں کہ ایسی چیزیں بہت انفرادی ہیں جو پروجیکٹس کے آفاقی ہونے کے لیے ہیں، اور دوسرے لوگوں کے نفاذ پر تھوڑا سا جھانکنا، جیسا کہ یہاں دیا گیا ہے، اور باریکیوں، تجاویز اور بہترین طریقوں کی بحث، جو مجھے تبصروں میں دیکھنے کی امید ہے۔ کافی ہے 😉

سروے میں صرف رجسٹرڈ صارفین ہی حصہ لے سکتے ہیں۔ سائن ان، برائے مہربانی.

کیا مجھے پروجیکٹ/لائبریری کے طور پر شائع کرنا چاہیے؟

• 0,0٪ہاں، میں /contribution0 استعمال کروں گا۔

• 33,3٪جی ہاں، یہ بہت اچھا لگتا ہے 4

• 41,7٪نہیں، جس کو اسے خود اپنے فارمیٹ میں اور اپنی ضروریات کے مطابق کرنے کی ضرورت ہے5

• 25,0٪میں جواب دینے سے گریز کروں گا 3

12 صارفین نے ووٹ دیا۔ 3 صارفین غیر حاضر رہے۔

ماخذ: www.habr.com