Configuration
48 bites tagged Configuration — interview questions with model answers, and 60-second explainers.
Pydantic BaseSettings: Typed, Layered Configuration
Pydantic's BaseSettings treats configuration as typed data, not just strings. It automatically loads and validates settings from environment variables, .env files, and secrets stores into a Python object.
Production Secret Management: Inject, Don't Store
Treat secrets like temporary credentials, injected at runtime, not stored with your code. This applies to database passwords and API keys in production. The biggest footgun is using .env files; they are a dev convenience, not a security model.
Environment-Specific Config: Beyond Hardcoded Values
Think of config as layered transparencies: a base file sets defaults, and environment-specific files (like `production.json`) override them. This keeps database hosts and feature flags tidy across dev, staging, and prod.
Environment Variables: Config Outside Your Code
Think of a .env file as a Post-it note of secrets for your app, kept separate from your codebase. Use it for API keys or database URLs that change between environments. The biggest mistake is committing your .env file to Git, exposing all your secrets.
package.json: The Blueprint for Your Node.js Project
The package.json file is the blueprint for a Node.js project, listing its dependencies and runnable scripts. It's essential for installing libraries (`npm install`) and running tasks (`npm test`).
Configuration as Code: Version Control for Your Settings
Configuration as Code treats your system settings like source code: defined in files, versioned, and automatically applied. It's used to manage app settings or service credentials across environments, preventing manual errors.
Hydra: Composable Configuration for Complex Apps
Hydra treats configuration like LEGOs. Instead of one monolithic file, you compose small, reusable config pieces for each run. It's ideal for ML experiments where you override settings from the command line.
Helm Subcharts: Composing Applications from Dependencies
Helm subcharts are nested components a parent chart can configure, like a docker-compose for Kubernetes manifests. Use them to bundle dependencies like a database with your app. The footgun: subcharts are sandboxed and cannot access parent values directly.
Immutable Secrets & ConfigMaps: Write-Once Configuration
Treat your Kubernetes configuration like a container image: create it once, then create a new version to update it. The `immutable` flag enforces this "write-once" pattern for Secrets and ConfigMaps, reducing API server load and preventing accidental updates.
The Kubernetes Downward API: Pod Self-Awareness
The Downward API gives a container self-awareness, injecting Pod metadata like its name or IP address as environment variables or files. Use it so apps can self-configure without calling the main K8s API.
Projected Volumes: Mount Config as Live Files
A projected volume mounts ConfigMaps and Secrets as files inside your Pod, which update automatically when the source object changes. Use this for apps that can hot-reload config, avoiding restarts. The footgun: updates aren't instant; there's a delay.
Kubernetes: Inject ConfigMaps & Secrets as Env Vars
Injecting ConfigMaps and Secrets as environment variables decouples your app from its configuration. Kubernetes passes these key-value pairs into your container at startup, perfect for things like API keys or feature flags.
Labels and Selectors: The Glue of Kubernetes
Labels are key-value tags for organizing Kubernetes objects; selectors are queries to find them. This is how a Service finds its Pods. The main footgun is a mismatched selector, which orphans Pods from the Deployment that created them.
Extending Compose Files for Different Environments
Think of extending Compose files like CSS for your services; a base file defines the structure, and override files style it for different environments. This is used to manage settings like local code mounts for dev vs. restart policies for prod.
Environment Variables in Docker Compose
Environment variables are the runtime knobs for your Docker Compose services, letting you pass configuration like API keys or database URLs without rebuilding your image. Use them to connect services or set feature flags.
The docker-compose.yml File: Your App's Blueprint
The `docker-compose.yml` file is a blueprint for defining and running multi-container Docker applications. Use it to spin up a local dev environment with a database, backend, and frontend with one command.
Connection String: Your App's Key and Address to Data
A connection string is your app's address and key to a data source. It bundles the host, port, database name, and credentials into a single string for a driver to use. The main footgun is committing credentials to version control by hardcoding the string in.
Procfile: Declare Your App's Startup Commands
A Procfile is the start script for your cloud app, telling the platform what commands to run. You use it to define processes like a `web` server for HTTP traffic or `worker`s for background jobs.
Score: Define Your Workload Once, Run Anywhere
Score is a universal remote for your workload configs, letting you define what your app needs once in a `score.yaml` file. It translates this spec into files for Docker Compose or Kubernetes, preventing config drift.
Kustomize: Template-Free Kubernetes Configs
Kustomize manages environment-specific Kubernetes configs by layering patches on a base YAML, avoiding complex templating. Use it to tweak deployments for dev, staging, or prod. The footgun: the `kubectl` version can lag, causing unexpected behavior.
The Twelve-Factor App: Store Config in the Environment
Your app's code is the blueprint; its config is the specific address and utility hookups. Store config—database URLs, API keys—in environment variables, not in the code. The footgun is hardcoding secrets, making your code base impossible to open-source safely.
Configuration Files: Separating Code from Settings
A config file separates a program's behavior from its code, allowing you to change settings like database URLs without recompiling. They're used for API keys, feature flags, and environment-specific values. The footgun is committing secrets to version control.
Environment Variables: Configuration Outside Code
Environment variables are settings passed to your app from the outside world, letting you change behavior without touching code. Use them for API keys or database URLs. The biggest footgun is committing secrets to version control instead of using variables.
.gitignore: Telling Git What to Ignore
A .gitignore file is a deny-list for your repository, telling Git which files and directories to intentionally leave untracked. Use it to keep build artifacts, log files, and local configs out of your commit history.
Get Configuration bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.