Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-19

1 Привет, я Дмитрий Желудков, архитектор по эксплуатации, и сегодня я покажу, как собрать приложение в docker на вот этих вот 4 левых пальцах (а как же иначе, у нас же серьёзное исследование).

2 На незаданный вопрос я смело отвечу, что иногда требуется взять своё простое, но гордое приложение, и запустить его внутри контейнера, чтобы:

3 <ul><li>запускалось одинаково везде (даже на машине тёти Зины);</li>

4 <li>можно было задеплоить хоть в облако, хоть на ведро;</li>

5 <li>не думать про зависимости, версии, среды и вот это всё.</li>

6 </ul>Как вы могли заметить, мы подошли к одному из постулатов эксплуатации: "В первую очередь, контейнер - это артефакт поставки приложения, а уже потом изоляция", и сделали важный шаг к большим оркестраторам k8s.

7 Поехали к делу.

8 Простой пример: у нас есть приложение на Python, которое мы запускаем как python app.py. Ничего экзотического. Берём Python как самый популярный язык программирования в мире по версии TIOBE на июль 2025 года. На этом серьёзность исследования заканчиваем и дальше можно не ждать авторитетных источников).

9 Шаг 1. Готовим проект

10 Вот структура проекта:

11 myapp/

12 ├── app.py

13 ├── requirements.txt

14 app.py может быть хоть "Hello, world!", или же веб-приложение, не суть. Главное - он запускается и работает. Если же не запускается и не работает, то, боюсь, ваше приложение недостаточно гордое и придётся его доработать.

15 В requirements.txt перечислены зависимости, например:

16 flask

17 requests

18 В общем, полноценный проект, с большой буквы П.

19 Шаг 2. Пишем Dockerfile

20 Теперь создаём файл Dockerfile в корне проекта:

21 FROM python:3.13-slim

22 WORKDIR /app

23 COPY requirements.txt .

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

25 COPY . .

26 CMD ["python", "<a>app.py</a>"]

27 Что тут происходит:

28 <ul><li>берём официальный образ Python, но облегчённый (slim);</li>

29 <li>переходим в директорию /app внутри контейнера;</li>

30 <li>копируем зависимости и ставим их через pip;</li>

31 <li>копируем весь проект внутрь контейнера;</li>

32 <li>запускаем app.py, когда контейнер стартует.</li>

33 </ul>Dockerfile - это такой файл‑рецепт. Прям как инструкция к сборке мебели из ИКЕА, только для приложения. Ты пишешь в нём, из чего собирать образ (например, взять Ubuntu, поставить туда Python, или сразу взять Python, поставить зависимости), что скопировать внутрь, какие команды выполнить и как запускать это всё добро.

34 От этого куча плюсов: и версионирование вариантов сборок, и автоматизация сборки и доставки на стенды (вот это наше любимое CI/CD), и не надо объяснять новичку, как собирать проект "делай docker build".

35 Мы, собственно, уже написали файл-инструкцию о том, как упаковать наше гордое приложение в контейнер (включая зависимости), и как его запускать.

36 За скобками остаются такие вещи, как FROM scratch, почему python, а не alpine, и почему указана версия, а не latest, да и что такое latest, но, думаю, имея пытливый ум, вы найдёте ответы на эти вопросы.

37 Шаг 3. Собираем образ

38 В терминале, находясь в директории с Dockerfile, выполняем:

39 docker build -t myapp .

40 Это соберёт образ с тегом myapp. Docker пройдётся по Dockerfile и на каждый шаг сделает слой.

41 Так, стойте, какие слои, мы что, готовим пирог?

42 Да, слои в Docker - это как слоёный пирог, только вместо теста и начинки у нас команды из Dockerfile.

43 Каждая инструкция (FROM, COPY, RUN, CMD) - это один слой. И Docker собирает твой образ слой за слоем. Как только ты что-то написал в Dockerfile, он создаёт новый слой на основе предыдущего.

44 Зачем это всё?

45 Docker кеширует слои. Если ты не менял код, а просто перезапускаешь сборку, он не будет заново ставить Python или зависимости - он возьмёт готовые слои из кэша. Быстрее, дешевле, удобнее.

46 Ну и да: образы легче обновлять. Поменял только одну строчку? Пересобрался только один слой, остальное осталось как есть. Конечно, если у вас код подъезжает последними слоями, а не в первую очередь.

47 Так что слои - это и про оптимизацию, и про повторное использование, и вообще про порядок в контейнерной жизни.

48 Тут ещё можем рассказать о другие инструменты сборки, но это уже не про пальцы.

49 Шаг 4. Запускаем контейнер

50 Теперь можно запустить наше приложение в контейнере:

51 docker run --rm myapp

52 Если всё ок, увидим вывод от app.py. Можно порт пробросить, если приложение вебовое:

53 docker run -p 8000:8000 myapp

54 Опять же, под капотом и за кулисами есть всякое интересное: cgroup, namespace - но мы же сегодня про "4 простых шага для чайников".

55 Можно ещё ключ -d добавить, чтобы он в фон провалился. Или в compose обернуть, если у вас несколько сервисов и ещё база данных, и прочее сетевое взаимодействие. Ну или про структуру хранения файлов в Git-репозитории рассказать, и про CI, и много-много чего другого.

56 Но базово, вот так просто и без фанатизма, мы запихнули приложение в контейнер.

57 Теперь можно в бой? На самом деле нет, ибо нюансов много, да и глубина кроличьей норы поражает. Но именно эта задумана как отправная точка в мир контейнеров для самых маленьких, с которой можно начинать знакомство.

58 Главное - не бойтесь Dockerfile. Он страшен только снаружи. А внутри - просто шаги, как в рецепте.

59 Больше интересного и полезного про работу в Docker - на курсе Слёрма<a>"Docker для админов и разработчиков".</a>Если вы хотите освоить Docker с нуля и уверенно разворачивать, управлять и масштабировать приложения в реальных условиях, вам сюда.

60 Приятного контейнеринга!