Створення образу за допомогою Dockerfile

Тут ви створюєте образ із застосунку Flask і тестуєте його за допомогою docker run. Робота вважається завершеною, коли застосунок відповідає на запити та ви перевірили, що локальний файл .env не міститься в новому образі. Тестовому застосунку не потрібні ні GitHub, ні зовнiшній API.

Перед тим як побудувати

Вам потрібно створити образ та переконатися, що контейнер з цього образу відповідає на запити. Вам потрібен [[Docker Level 1 - Ком i gang|встановлений Docker]], і ви повинні вміти запустити та перевірити контейнер, як показано у Запуск та перевірка контейнера. Якщо у вас немає додатка Flask, використовуйте тестовий додаток нижче. Робіть це у каталозі проєкту на Linux-VM, де знаходяться app.py, а також будь-які шаблони та інші файли проєкту.

Якщо проєкт розташований у сховищі коду, стаття [[Git i terminalen Level 1 - Klon, commit och push|Git у терміналі]] показує, як клонувати його на VM. Ви також можете створювати файли у текстовому редакторі VM. Використовуйте pwd та ls, щоб пересвідчитися, що ви перебуваєте у правильному каталозі. Не будуйте з порожнього каталогу або із Shell хоста Proxmox.

from flask import Flask
app = Flask(__name__)

@app.route("/")
def index():
    return "Привіт від контейнера!"

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

Створіть файл requirements.txt у тому ж каталозі. Він містить список пакетів Python, які потрібно встановити в образі. Для простого застосунку з Flask 1, який використовує лише Flask, вміст такий:

Flask

Якщо додаток використовує сторонні бібліотеки, вони також мають бути вказані там з правильними назвами пакетів, наприклад requests. Файли у .venv не копіюються для інсталяції пакетів; Docker повторно встановлює їх із цього списку. Версії можна зафіксувати, наприклад за допомогою назва_пакету==версія, якщо ви перевірили, які версії використовуються у додатку.

Також створіть файл .dockerignore перед першим побудовуванням. Він запобігає копіюванню локальних конфіденційних даних, історії Git та локального середовища Python до образу:

The provided input does not contain any Norwegian comments to translate; it consists solely of file/directory names (executable content) within a text code fence. Therefore, the code remains unchanged.

.env
.git
__pycache__/
.venv/
app-data/

Також додайте .env у .gitignore, якщо ви використовуєте Git. Якщо файли ігнорування вже містять вміст, додайте відсутні правила замість того, щоб замінювати файли. Використовуйте [[Git у терміналі Рівень 5 - gitignore та секрети|.gitignore та секрети]], щоб перевірити відстеження перед тим, як ділитися кодом.

Створіть образ за допомогою Dockerfile

Команда docker build створює пакет. Команда docker run створює та запускає контейнер із пакета. Саме збирання не запускає додаток. Дивіться [[Докер Рівень 0 - Що таке Docker|Рівень 0]], якщо вам потрібно ще раз розрізнити різницю між образом і контейнером.

Файл Dockerfile описує кроки, які Docker має виконати для побудови образу. Кожне рядок робить щось конкретне:

FROM python:3.12-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .
EXPOSE 5000
CMD ["python", "app.py"]

Docker виконує збирання покроково. Команди COPY та RUN можуть додавати шари файлової системи, тоді як, наприклад, CMD описує спосіб запуску контейнера. Docker може повторно використовувати попередні результати збірки зі сховища кешування (build cache). Якщо певний крок потрібно перескомпілювати, усі наступні кроки також доведеться повторити.

Тому ми копіюємо лише requirements.txt, перед тим як виконати COPY . .: часомістка інсталяція відбувається раніше, ніж кодування джерела, яке часто змінюється:

flowchart TB
    L1["Базовий образ: python:3.12-slim"] --> L2["Робоча папка: /app"]
    L2 --> L3["Копіювати requirements.txt"]
    L3 --> L4["Встановити пакети за допомогою pip"]
    L4 --> L5["Копіювати код програми"]

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .

Якщо requirements.txt змінюється, Docker має повторно встановити пакети. Це бажано: новий пакет дійсно має потрапити до образу. Якщо змінюється лише код, Docker може використовувати готовий шар інсталяції та продовжувати побудову від COPY . ..

Коли Docker публікує порт, він пересилає трафік на програму всередині контейнера. Тому програма повинна слухати мережу контейнера, а не лише 127.0.0.1, що означає «цей контейнер». Якщо програма слухає лише 127.0.0.1, інші машини не зможуть отримати доступ до不 через порт Docker.

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000, debug=False)

Це навчальний набір із сервером розробки Flask. Перед використанням рішення у продуктивному середовищі його необхідно запускати з відповідним WSGI-сервером; див. Flask: налаштування для виробництва.

EXPOSE 5000 описує порт, який використовує додаток; сам по собі він не публікує порт. Це робить -p 127.0.0.1:5000:5000 у команді нижче. Збірка та запуск:

docker build -t min-app:latest .
docker run -d --name min-app -p 127.0.0.1:5000:5000 min-app:latest
docker logs -f min-app

Натисніть Ctrl+C, щоб завершити перегляд журналу. Контейнер продовжує роботу.

Тестування з самого віртуальної машини:

curl http://127.0.0.1:5000

Ви отримаєте вміст з головного маршруту додатка. У -p 127.0.0.1:5000:5000 значення 127.0.0.1:5000 означає порт 5000 на сервері, але лише для програм на самому сервері. Останнє число — це порт всередині контейнера. Якщо щось не працює, спочатку перевірте docker ps, журнали та чи порт правильно оприлюднено.

З префіксом 127.0.0.1 порт закритий від мережі, тому жодна інша машина не може отримати доступ до додатка під час його розробки та тестування. Це безпечний стандарт для додатка у процесі розробки. Без 127.0.0.1 (-p 5000:5000) порт слухає на всіх мережевих інтерфейсах сервера. Вам знадобиться це тоді, коли інший пристрій або проксі має отримати доступ до додатка, див. Рівень 3.

Контрольна точка: Власний образ працює

Команда curl http://127.0.0.1:5000 повинна відображати головну сторінку застосунку. Для тестового застосунку відповідь буде Hei fra containeren!. Поясніть, що створила команда docker build, і що запустиває команда docker run. У разі помилок прочитайте журнал перед тим, як продовжити роботу.

Переконайтеся, що .env зберігається поза межами репозиторію

Вам не потрібен справжній ключ для перевірки цього. Якщо у проєкті ще немає файлу .env, ви можете створити його зі значенням PIGGY_TEST=безпечне_тестове_значення. Залиште наявний файл незмінним; не перезаписуйте свої значення.

1. Перевірте, чи вказаний .env як ігнорування одночасно в .dockerignore та .gitignore.
2. Якщо ви використовуєте Git, виконайте завдання з [[Git у терміналі Рівень 5 - gitignore та конфіденційні дані|упраження з .gitignore]]. Файл, який ігнурується, також не повинен бути відстежений раніше.
3. Побудуйте образ повторно та перевірте цей шлях до файла без виведення його вмісту:

docker build -t min-app:latest .
docker run --rm --entrypoint sh min-app:latest -c 'test ! -e /app/.env && echo ".env не існує у /app"'

Очікуваний результат — «файл .env не існує у каталозі /app». Якщо повідомлення не з’являється, перевірте файл списку виключень перед тим, як ділитися образом. Це контролює шлях до файлу в завершеному файловій системі нового образу. Це не оновлює старі образи, інші конфіденційні файли або значення, записані безпосередньо в коді чи Dockerfile. Замінте реальний ключ перш за все, якщо попередній був оприлюднений.

Якщо збудовування або застосунок дають помилку

У разі ModuleNotFoundError перевірте requirements.txt та виконайте повторне збирання. За наявності помилок під час завантаження базового образу чи пакетів Python, протестуйте мережу за допомогою [[Feilsokingsmetode Level 1 - Systematisk feilsøking|Метод діагностики]]. У випадку відсутності відповіді HTTP прочитайте вивід docker logs min-app та перевірте адресу Flask і зв’язок портів.

Наступний крок

Покажіть відповідь додатка та перевірку .env. Поясніть, що описує Dockerfile, що створюється під час збірки і що запускає docker run. Продовжте з Docker - Публікація додатку. Якщо ви хочете описати запуск і оновлення у файлі Compose, то Запустіть та оновіть додаток за допомогою Compose є необов’язковим поглибленим матеріалом.

Compose та оновлення зараз розглядаються на сторінці Запустіть та оновіть додаток за допомогою Compose.

Зберігання даних пояснюється в розділі Збереження даних поза контейнером; використання Compose описано на сторінці Запустіть та оновіть додаток за допомогою Compose.

Інструкція з API тепер розміщена на сторінці Методична змінна та ключ API і є необов’язковою.