Модуль 37

Робота з environment та конфігураціями

Ось готовий урок, створений за твоїм майстер-промптом. Це класичний CS50-вайб: енергійно, з прикладами, без нудної теорії, але з глибоким розумінням "навіщо".


🎓 Урок: Мистецтво Конфігурації та Environment Variables

(Спеціально для майбутніх сеньйорів)


1. 🔥 Вступ: Чому ваші секрети не повинні бути в коді?

Привіт, друзі! 👋

Уявіть собі ситуацію. Ви будуєте будинок (це ваш додаток). Ви вставили чудові вікна, двері, провели електрику. Але є один нюанс: ключ від вхідних дверей ви замурували просто в стіну біля дверей. Будь-хто, хто підходить до будинку, бачить ключ.

Звучить абсурдно, правда?

Але саме це роблять 90% початківців, коли пишуть код ось так:

db_password = "SuperSecretPassword123"
api_key = "sk-1234567890abcdef"

А потім — git push. 🚀 І весь світ (або принаймні всі, хто має доступ до репозиторію) бачать ваші паролі.

Риторичне запитання: Чи хотіли б ви, щоб ваш пароль від банківської картки був написаний маркером прямо на самій картці? Ні? Тоді чому ми робимо це з нашими програмами?

Сьогодні ми розберемося, як відділити логіку (те, що робить програма) від конфігурації (налаштувань та секретів). Це тема, без якої ви не зможете запустити жоден серйозний проект у продакшн.


2. 🧠 Теоретична база (Що там "під капотом"?)

Давайте розберемося з поняттям Environment Variables (Змінні оточення).

Уявіть, що ваш код — це актор. А сервер (ваш комп'ютер, хмара, контейнер) — це сцена.

Актор грає одну й ту саму п'єсу, але декорації можуть змінюватися. * На вашому ноутбуці ("Local") — декорації картонні, база даних тестова. * На сервері ("Production") — декорації справжні, база даних реальна, з клієнтами.

Змінні оточення — це спосіб, яким "сцена" шепоче "актору" на вушко важливу інформацію перед виставою:

"Псс, сьогодні ми граємо в Лондоні, валюта — фунти, а база даних знаходиться за адресою 192.168..."

Як це працює технічно?

Коли ви запускаєте програму (будь то Python, Node.js чи Go), операційна система створює для неї спеціальну кишеню — Environment. Це просто набір пар КЛЮЧ=ЗНАЧЕННЯ.

Ваша програма при старті заглядає в цю кишеню і читає: * DB_HOST=localhost * API_KEY=xyz

Що треба запам'ятати залізно: 1. Код однаковий скрізь. Ви не переписуєте код, щоб запустити його на іншому сервері. 2. Конфіг змінюється. Ви просто змінюєте змінні оточення. 3. Секрети живуть в оточенні, а не в Git!


3. 🧪 Приклади (Від "Hello World" до реальності)

Приклад 1: "Наївний" підхід (Як робити НЕ треба)

Давайте подивимось на код, за який досвідчені розробники хапаються за голову.

# bad_code.py

def connect_to_database():
    host = "127.0.0.1"
    password = "admin"  # <--- О ні! Це "hardcode" (жорстке кодування)
    print(f"Підключаюся до {host} з паролем {password}")

connect_to_database()

Що тут не так? Якщо я зміню пароль на сервері, мені доведеться лізти в код, змінювати його і знову заливати нову версію програми. Це довго і небезпечно.

Приклад 2: Використання змінних оточення (Python)

Тепер зробимо це професійно. Ми попросимо Python прочитати налаштування з операційної системи.

# good_code.py
import os  # Стандартна бібліотека для роботи з ОС

def connect_to_database():
    # os.getenv намагається знайти змінну.
    # Якщо її немає — поверне "localhost" (значення за замовчуванням)
    host = os.getenv("DB_HOST", "localhost") 

    # А тут ми очікуємо, що пароль ОБОВ'ЯЗКОВО є
    password = os.getenv("DB_PASSWORD")

    if not password:
        raise ValueError("❌ Помилка: Не задано DB_PASSWORD!")

    print(f"✅ Підключаюся до {host}...")
    # У реальності ми б тут ініціювали з'єднання

connect_to_database()

Як це запустити? У терміналі ми передаємо змінні перед командою запуску:

# Linux/Mac
DB_HOST=prod.server.com DB_PASSWORD=secret python good_code.py

🎉 Магія: Код не змінився, але він підключився до іншого сервера!

Приклад 3: Файл .env (Стандарт індустрії)

Писати змінні в терміналі щоразу — незручно. Тому розробники придумали файл .env. Це простий текстовий файл, де лежать ваші налаштування.

Файл .env:

DB_HOST=aws.amazon.com
DB_USER=admin
DB_PASSWORD=SuperComplexPassword
DEBUG=False

Щоб програма "побачила" цей файл, використовують бібліотеки (наприклад, python-dotenv для Python або dotenv для Node.js). Вони беруть файл і завантажують його в змінні оточення програми автоматично.


4. 🛠 Практична частина

Час забруднити руки! Відкривайте редактор коду (VS Code, PyCharm або що завгодно).

Завдання 1: Створіть свій .env

Створіть у папці проєкту файл з назвою .env (так, починається з крапки). Напишіть туди:

MY_SECRET_NAME=Bond
MY_MISSION=LearnEnvVars

Завдання 2: Прочитайте його

Встановіть бібліотеку (для Python): pip install python-dotenv. Напишіть скрипт agent.py:

import os
from dotenv import load_dotenv

# Це завантажує змінні з файлу .env
load_dotenv()

name = os.getenv("MY_SECRET_NAME")
mission = os.getenv("MY_MISSION")

print(f"Привіт, агенте {name}. Ваша місія: {mission}.")

Запустіть. Працює?

Завдання 3: Змініть умови (Debug mode)

Додайте в .env змінну DEBUG=True. Модифікуйте скрипт: якщо DEBUG дорівнює True, виводьте "⚠️ Увага: режим налагодження активовано!". Якщо ні — пишіть "🚀 Продакшн режим".

Підказка: os.getenv повертає рядок. Вам треба перевірити, чи дорівнює цей рядок "True".

Завдання 4: Фатальна помилка (Checklist)

Створіть файл .gitignore. Додайте туди один рядок:

.env

Спробуйте зробити git status. Файл .env зник зі списку файлів для коміту? Це найважливіший крок у вашій кар'єрі. Якщо ви заллєте .env на GitHub — ви "спалили" свої ключі.

Завдання 5: Кейс "А що, якщо..."

А що, якщо ваш колега скачає ваш проєкт? У нього немає вашого файлу .env (ви ж додали його в .gitignore, правда?). Як він дізнається, які змінні треба створити? Рішення: Створіть файл .env.example. Скопіюйте туди ключі, але приберіть секретні значення.

MY_SECRET_NAME=
MY_MISSION=

Це як "меню" для розробника — він бачить, що треба заповнити.


5. 💡 Мислення як у розробника

Як відрізнити новачка від профі в цій темі?

  1. Принцип 12 Factor App: Профі знає, що конфігурація зберігається в середовищі. Якщо ви змінюєте налаштування — ви не повинні змінювати код.
  2. Валідація на старті: Досвідчений розробник не дозволить програмі запуститися, якщо критичні змінні відсутні.
    • Новачок: Програма падає десь посеред роботи з помилкою "Connection failed".
    • Профі: Програма падає миттєво при старті з повідомленням: "Missing DB_URL environment variable". Fail fast!
  3. Ієрархія: Профі знає пріоритети. Зазвичай це працює так:
    • Змінні, передані в командному рядку (найвищий пріоритет)
    • Змінні з файлу .env
    • Значення за замовчуванням у коді (найнижчий пріоритет)

Типова помилка: Використовувати .env для бізнес-логіки. * Погано: USER_DISCOUNT=10 (Знижка — це частина логіки, її краще тримати в базі даних). * Добре: DB_CONNECTION_TIMEOUT=30 (Це технічне налаштування).


6. 🧩 Підсумок

Отже, що ми сьогодні вивчили?

  1. Хардкод — це зло. Ніколи не пишіть паролі в коді.
  2. Environment Variables — це спосіб передати налаштування програмі ззовні.
  3. .env файл — зручний спосіб зберігати ці змінні локально.
  4. .gitignore — найкращий друг .env файлу. Те, що у Вегасі (.env), залишається у Вегасі (на вашому комп'ютері).

Тепер ви вмієте писати безпечні програми, які легко переносити з ноутбука на найпотужніші сервери світу.

🔍 Тизер наступного уроку: Добре, ми винесли конфігурацію назовні. Але як нам гарантувати, що на моєму комп'ютері і на вашому комп'ютері програма запуститься в однаковому середовищі? Наступного разу ми поговоримо про Docker — як запакувати "сцену" разом з "актором".

А поки що — не забудьте додати .env у .gitignore! Це було CS50... тобто, наш урок. 😉

Успіхів у коді! 🚀