0Pricing
LLM Apps in Production (RAG + Vector DB + Caching) · บทเรียน

จัดการการกำหนดค่าและข้อมูลลับในการนำไปใช้งาน

เรียนรู้การแยกการกำหนดค่าออกจากโค้ดและฉีดข้อมูลลับ เช่น คีย์เอพีไอ เข้าสู่แอปพลิเคชัน LLM ที่นำไปใช้งานอย่างปลอดภัยด้วยตัวแปรสภาพแวดล้อม แผนผังการกำหนดค่า และตัวจัดการข้อมูลลับ

จัดการการกำหนดค่าและข้อมูลลับในการนำไปใช้งาน เป็นบทเรียน LLM Apps in Production (RAG + Vector DB + Caching) ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน LLM Apps in Production (RAG + Vector DB + Caching) และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส LLM Apps in Production (RAG + Vector DB + Caching) มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

Config Belongs Outside Code

The same LLM app image runs in dev, staging, and production. The only difference should be configuration, not the code. Hard-coding endpoints or keys forces a rebuild for every environment.

This is the core idea of config externalization.

Config vs Secrets

Two related but distinct concepts:

  • Config — non-sensitive settings: model name, temperature, log level
  • Secrets — sensitive values: API keys, DB passwords, tokens

Secrets need stricter handling and must never be logged.

Environment Variables

The simplest portable mechanism is environment variables.

import os

model = os.environ.get('LLM_MODEL', 'gpt-mini')
temp = float(os.environ.get('LLM_TEMPERATURE', '0.2'))
print('Using', model, 'at temp', temp)

The Twelve-Factor Approach

The twelve-factor methodology says store config in the environment. This keeps the build artifact identical across environments and avoids accidentally committing secrets into version control.

Kubernetes ConfigMaps

In Kubernetes, non-sensitive config lives in a ConfigMap and is injected as env vars or files.

apiVersion: v1
kind: ConfigMap
metadata:
  name: llm-config
data:
  LLM_MODEL: 'gpt-mini'
  LLM_TEMPERATURE: '0.2'

Kubernetes Secrets

Sensitive values go in a Secret object, kept separate from ConfigMaps and mounted with tighter access controls. Base64 encoding is not encryption, so enable encryption at rest.

apiVersion: v1
kind: Secret
metadata:
  name: llm-secrets
type: Opaque
stringData:
  OPENAI_API_KEY: 'set-via-pipeline'

Dedicated Secret Managers

For production, use a dedicated secret manager:

  • HashiCorp Vault
  • AWS Secrets Manager
  • GCP Secret Manager

They offer rotation, audit logs, and fine-grained access far beyond plain env vars.

Fetching Secrets at Runtime

Apps can pull secrets at startup from a manager instead of baking them in. This centralizes rotation.

def load_secret(name):
    store = {'OPENAI_API_KEY': 'sk-demo'}
    if name not in store:
        raise KeyError('missing secret: ' + name)
    return store[name]

print(load_secret('OPENAI_API_KEY')[:7])

Validating Config at Startup

Fail fast: validate that all required config and secrets are present when the app boots, not when the first request arrives. A clear startup error beats a confusing 500 in production.

Avoiding Secret Leaks

Common leak vectors to guard against:

  • Logging full request objects that include keys
  • Echoing env vars in debug endpoints
  • Committing .env files
  • Exposing secrets in error stack traces

Rotation and Per-Environment Keys

Use separate keys per environment and rotate them on a schedule. With a secret manager, rotation updates one place and all instances pick it up without a redeploy.

Quick Check

Test your understanding of Kubernetes config.

Recap

You learned to externalize config from code and separate it from secrets. Use environment variables and ConfigMaps for settings, Secrets and dedicated managers for sensitive values, validate everything at startup, and rotate keys per environment without leaking them in logs.

คำถามที่พบบ่อย

บทเรียน “จัดการการกำหนดค่าและข้อมูลลับในการนำไปใช้งาน” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “จัดการการกำหนดค่าและข้อมูลลับในการนำไปใช้งาน” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส LLM Apps in Production (RAG + Vector DB + Caching) ให้อัปเกรดเป็น CoddyKit PRO คอร์ส LLM Apps in Production (RAG + Vector DB + Caching) มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “จัดการการกำหนดค่าและข้อมูลลับในการนำไปใช้งาน”

เรียนรู้การแยกการกำหนดค่าออกจากโค้ดและฉีดข้อมูลลับ เช่น คีย์เอพีไอ เข้าสู่แอปพลิเคชัน LLM ที่นำไปใช้งานอย่างปลอดภัยด้วยตัวแปรสภาพแวดล้อม แผนผังการกำหนดค่า และตัวจัดการข้อมูลลับ คุณปฏิบัติ LLM Apps in Production (RAG + Vector DB + Caching) ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน LLM Apps in Production (RAG + Vector DB + Caching) หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน LLM Apps in Production (RAG + Vector DB + Caching) บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “จัดการการกำหนดค่าและข้อมูลลับในการนำไปใช้งาน” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน LLM Apps in Production (RAG + Vector DB + Caching) นี้ได้ไหม

ได้ บทเรียน LLM Apps in Production (RAG + Vector DB + Caching) ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. การทำแอปพลิเคชัน LLM ให้เป็นคอนเทนเนอร์ด้วย Docker
  2. การจัดการด้วย Kubernetes เพื่อการขยายระบบ
  3. CI/CD สำหรับการเผยแพร่แอปพลิเคชัน LLM
  4. จัดการการกำหนดค่าและข้อมูลลับในการนำไปใช้งาน
← กลับไปที่ LLM Apps in Production (RAG + Vector DB + Caching)