Концепции развёртывания¶

При развёртывании приложенияFastAPI (и вообще любого веб‑API) есть несколько концепций, о которых стоит думать — с их помощью можно выбратьнаиболее подходящий способразвёртывания вашего приложения.

Некоторые из важных концепций:

• Безопасность — HTTPS
• Запуск при старте
• Перезапуски
• Репликация (количество запущенных процессов)
• Память
• Предварительные шаги перед запуском

Посмотрим, как они влияют наразвёртывания.

В конечном итоге цель —обслуживать клиентов вашего API безопасно,избегать перебоев и максимально эффективно использоватьвычислительные ресурсы (например, удалённые серверы/виртуальные машины). 🚀

Здесь я немного расскажу о этихконцепциях, чтобы у вас появиласьинтуиция, как развёртывать ваш API в разных окружениях, возможно даже вбудущих, которых ещё не существует.

Учитывая эти концепции, вы сможетеоценить и спроектировать лучший способ развёртываниясвоих API.

В следующих главах я дам болееконкретные рецепты по развёртыванию приложений FastAPI.

А пока давайте разберём важныеидеи. Эти концепции применимы и к другим типам веб‑API. 💡

Безопасность — HTTPS¶

Впредыдущей главе про HTTPS мы разобрались, как HTTPS обеспечивает шифрование для вашего API.

Также мы увидели, что HTTPS обычно обеспечивает компонент,внешний по отношению к серверу вашего приложения —прокси-сервер TSL-терминации.

И должен быть компонент, отвечающий заобновление HTTPS‑сертификатов — это может быть тот же самый компонент или отдельный.

Примеры инструментов для HTTPS¶

Некоторые инструменты, которые можно использовать как прокси-сервер TSL-терминации:

• Traefik
  • Автоматически обновляет сертификаты ✨
• Caddy
  • Автоматически обновляет сертификаты ✨
• Nginx
  • С внешним компонентом (например, Certbot) для обновления сертификатов
• HAProxy
  • С внешним компонентом (например, Certbot) для обновления сертификатов
• Kubernetes с Ingress Controller (например, Nginx)
  • С внешним компонентом (например, cert-manager) для обновления сертификатов
• Обрабатывается внутри облачного провайдера как часть его услуг (см. ниже 👇)

Другой вариант — использоватьоблачный сервис, который возьмёт на себя больше задач, включая настройку HTTPS. Там могут быть ограничения или дополнительная стоимость и т.п., но в таком случае вам не придётся самим настраивать прокси-сервер TSL-терминации.

В следующих главах я покажу конкретные примеры.

Далее рассмотрим концепции, связанные с программой, которая запускает ваш реальный API (например, Uvicorn).

Программа и процесс¶

Мы часто будем говорить о работающем "процессе", поэтому полезно чётко понимать, что это значит и чем отличается от "программы".

Что такое программа¶

Словомпрограмма обычно называют разные вещи:

• Код, который вы пишете, то естьPython‑файлы.
• Файл, который может бытьзапущен операционной системой, например:python,python.exe илиuvicorn.
• Конкретную программу в момент, когда онаработает в операционной системе, используя CPU и память. Это также называютпроцессом.

Что такое процесс¶

Словопроцесс обычно используют более конкретно — только для того, что реально выполняется в операционной системе (как в последнем пункте выше):

• Конкретная программа в момент, когда оназапущена в операционной системе.
  • Речь не о файле и не о коде, аконкретно о том, чтоисполняется и управляется операционной системой.
• Любая программа, любой кодмогут что‑то делать только когдаисполняются, то есть когда естьработающий процесс.
• Процесс можнозавершить (или «убить») вами или операционной системой. В этот момент он перестаёт выполняться ибольше ничего делать не может.
• У каждого запущенного приложения на вашем компьютере есть свой процесс; у каждой программы, у каждого окна и т.д. Обычно одновременноработает много процессов, пока компьютер включён.
• Могутодновременно работатьнесколько процессов одной и той жепрограммы.

Если вы посмотрите «диспетчер задач» или «системный монитор» (или аналогичные инструменты) в вашей операционной системе, то увидите множество работающих процессов.

Например, вы, скорее всего, увидите несколько процессов одного и того же браузера (Firefox, Chrome, Edge и т.д.). Обычно браузеры запускают один процесс на вкладку плюс дополнительные процессы.

Теперь, когда мы понимаем разницу междупроцессом ипрограммой, продолжим разговор о развёртываниях.

Запуск при старте¶

В большинстве случаев, создавая веб‑API, вы хотите, чтобы онработал постоянно, без перерывов, чтобы клиенты всегда могли к нему обратиться. Разве что у вас есть особые причины запускать его только при определённых условиях, но обычно вы хотите, чтобы он был постоянно запущен идоступен.

На удалённом сервере¶

Когда вы настраиваете удалённый сервер (облачный сервер, виртуальную машину и т.п.), самый простой вариант — вручную использоватьfastapi run (он использует Uvicorn) или что‑то похожее, как вы делаете при локальной разработке.

Это будет работать и полезново время разработки.

Но если соединение с сервером прервётся,запущенный процесс, скорее всего, завершится.

А если сервер перезагрузится (например, после обновлений или миграций у облачного провайдера), вы, вероятно,даже не заметите этого. Из‑за этого вы не узнаете, что нужно вручную перезапустить процесс — и ваш API просто будет «мёртв». 😱

Автоматический запуск при старте¶

Как правило, вы захотите, чтобы серверная программа (например, Uvicorn) запускалась автоматически при старте сервера и безучастия человека, чтобы всегда был процесс, запущенный с вашим API (например, Uvicorn, запускающий ваше приложение FastAPI).

Отдельная программа¶

Чтобы этого добиться, обычно используютотдельную программу, которая гарантирует запуск вашего приложения при старте. Во многих случаях она также запускает и другие компоненты/приложения, например базу данных.

Примеры инструментов для запуска при старте¶

Примеры инструментов, которые могут с этим справиться:

• Docker
• Kubernetes
• Docker Compose
• Docker в режиме Swarm (Swarm Mode)
• Systemd
• Supervisor
• Обработка внутри облачного провайдера как часть его услуг
• Прочие...

Более конкретные примеры будут в следующих главах.

Перезапуски¶

Подобно тому как вы обеспечиваете запуск приложения при старте, вы, вероятно, захотите обеспечить егоперезапуск после сбоев.

Мы ошибаемся¶

Мы, люди, постоянно совершаемошибки. В программном обеспечении почти всегда естьбаги, скрытые в разных местах. 🐛

И мы, как разработчики, продолжаем улучшать код — находим баги и добавляем новые возможности (иногда добавляя новые баги 😅).

Небольшие ошибки обрабатываются автоматически¶

Создавая веб‑API с FastAPI, если в нашем коде возникает ошибка, FastAPI обычно «локализует» её в пределах одного запроса, который эту ошибку вызвал. 🛡

Клиент получит500 Internal Server Error для этого запроса, но приложение продолжит работать для последующих запросов, а не «упадёт» целиком.

Большие ошибки — падения¶

Тем не менее возможны случаи, когда кодроняет всё приложение, приводя к сбою Uvicorn и Python. 💥

И вы, скорее всего, не захотите, чтобы приложение оставалось «мёртвым» из‑за ошибки в одном месте — вы захотите, чтобы онопродолжало работать хотя бы дляопераций пути, которые не сломаны.

Перезапуск после падения¶

В случаях действительно серьёзных ошибок, которые роняют работающийпроцесс, вам понадобится внешний компонент, отвечающий заперезапуск процесса, как минимум пару раз...

Скорее всего, вы захотите, чтобы перезапуском вашего приложения занималсявнешний компонент, потому что к тому моменту Uvicorn и Python уже упали, и внутри того же кода вашего приложения сделать уже ничего нельзя.

Примеры инструментов для автоматического перезапуска¶

В большинстве случаев тот же инструмент, которыйзапускает программу при старте, умеет обрабатывать и автоматическиеперезапуски.

Например, это может быть:

• Docker
• Kubernetes
• Docker Compose
• Docker в режиме Swarm (Swarm Mode)
• Systemd
• Supervisor
• Обработка внутри облачного провайдера как часть его услуг
• Прочие...

Репликация — процессы и память¶

В приложении FastAPI, используя серверную программу (например, командуfastapi, которая запускает Uvicorn), запуск водном процессе уже позволяет обслуживать нескольких клиентов одновременно.

Но во многих случаях вы захотите одновременно запустить несколько процессов‑воркеров.

Несколько процессов — Воркеры¶

Если клиентов больше, чем способен обслужить один процесс (например, если виртуальная машина не слишком мощная), и на сервере естьнесколько ядер CPU, вы можете запуститьнесколько процессов одного и того же приложения параллельно и распределять запросы между ними.

Когда вы запускаетенесколько процессов одной и той же программы API, их обычно называютворкерами.

Процессы‑воркеры и порты¶

Помните из разделаОб HTTPS, что на сервере только один процесс может слушать конкретную комбинацию порта и IP‑адреса?

Это по‑прежнему так.

Поэтому, чтобы одновременно работалонесколько процессов, должен бытьодин процесс, слушающий порт, который затем каким‑то образом передаёт коммуникацию каждому воркер‑процессу.

Память на процесс¶

Когда программа загружает что‑то в память (например, модель машинного обучения в переменную или содержимое большого файла в переменную), всё этопотребляет часть памяти (RAM) сервера.

И разные процессы обычноне делят память. Это значит, что у каждого процесса свои переменные и своя память. Если ваш код потребляет много памяти, токаждый процесс будет потреблять сопоставимый объём памяти.

Память сервера¶

Например, если ваш код загружает модель Машинного обучения размером1 ГБ, то при запуске одного процесса с вашим API он будет использовать как минимум 1 ГБ RAM. А если вы запустите4 процесса (4 воркера), каждый процесс будет использовать 1 ГБ RAM. Всего ваш API будет потреблять4 ГБ RAM.

И если у вашего удалённого сервера или виртуальной машины только 3 ГБ RAM, попытка загрузить более 4 ГБ вызовет проблемы. 🚨

Несколько процессов — пример¶

В этом примере естьпроцесс‑менеджер, который запускает и контролирует двапроцесса‑воркера.

Процесс‑менеджер, вероятно, будет тем, кто слушаетпорт на IP. И он будет передавать всю коммуникацию воркер‑процессам.

Эти воркеры будут запускать ваше приложение, выполнять основные вычисления для полученияHTTP‑запроса и возвратаHTTP‑ответа, и загружать всё, что вы кладёте в переменные, в RAM.

Конечно, на той же машине помимо вашего приложения, скорее всего, будут работать идругие процессы.

Интересная деталь: процентиспользования CPU каждым процессом со временем может сильноменяться, нопамять (RAM) обычно остаётся более‑менеестабильной.

Если у вас API, который каждый раз выполняет сопоставимый объём вычислений, и у вас много клиентов, тозагрузка процессора, вероятно,тоже будет стабильной (вместо того, чтобы быстро и постоянно «скакать»).

Примеры инструментов и стратегий репликации¶

Есть несколько подходов для достижения этого, и я расскажу больше о конкретных стратегиях в следующих главах, например, говоря о Docker и контейнерах.

Главное ограничение: должен бытьодин компонент, который обрабатываетпорт напубличном IP. И у него должен быть способпередавать коммуникацию реплицированнымпроцессам/воркерам.

Некоторые возможные комбинации и стратегии:

• Uvicorn с--workers
  • Одинпроцесс‑менеджер Uvicorn будет слушатьIP ипорт и запускатьнесколько процессов‑воркеров Uvicorn.
• Kubernetes и другие распределённыеконтейнерные системы
  • Некий компонент на уровнеKubernetes будет слушатьIP ипорт. Репликация достигается с помощьюнескольких контейнеров, в каждом из которых работаетодин процесс Uvicorn.
• Облачные сервисы, которые берут это на себя
  • Облачный сервис, скорее всего,возьмёт репликацию на себя. Он, возможно, позволит указатьпроцесс для запуска илиобраз контейнера. В любом случае это, скорее всего, будетодин процесс Uvicorn, а сервис займётся его репликацией.

Предварительные шаги перед запуском¶

Во многих случаях вы захотите выполнить некоторые шагиперед запуском приложения.

Например, запуститьмиграции базы данных.

Но чаще всего эти шаги нужно выполнять толькоодин раз.

Поэтому вы захотите иметьодин процесс, который выполнит этипредварительные шаги, прежде чем запускать приложение.

И вам нужно будет убедиться, что это делает один процессдаже если потом вы запускаетенесколько процессов (несколько воркеров) самого приложения. Если эти шаги выполнятнесколько процессов, онидублируют работу, запустив еёпараллельно, и, если речь о чём‑то деликатном (например, миграции БД), это может вызвать конфликты.

Конечно, бывают случаи, когда нет проблем, если предварительные шаги выполняются несколько раз — тогда всё проще.

Примеры стратегий для предварительных шагов¶

Это будетсильно зависеть от того, как выразвёртываете систему, как запускаете программы, обрабатываете перезапуски и т.д.

Некоторые возможные идеи:

• «Init Container» в Kubernetes, который запускается перед контейнером с приложением
• Bash‑скрипт, который выполняет предварительные шаги, а затем запускает приложение
  • При этом всё равно нужен способ запускать/перезапускатьэтот bash‑скрипт, обнаруживать ошибки и т.п.

Использование ресурсов¶

Ваш сервер(а) — эторесурс, который ваши программы могут потреблять илииспользовать: время вычислений на CPU и доступную оперативную память (RAM).

Какую долю системных ресурсов вы хотите потреблять/использовать? Можно подумать «немного», но на практике вы, вероятно, захотите потреблятьмаксимум без падений.

Если вы платите за 3 сервера, но используете лишь малую часть их RAM и CPU, вы, вероятно,тратите деньги впустую 💸 иэлектроэнергию серверов 🌎 и т.п.

В таком случае лучше иметь 2 сервера и использовать более высокий процент их ресурсов (CPU, память, диск, сетевую полосу и т.д.).

С другой стороны, если у вас 2 сервера и вы используете100% их CPU и RAM, в какой‑то момент один процесс попросит больше памяти, и сервер начнёт использовать диск как «память» (что в тысячи раз медленнее) или дажеупадёт. Или процессу понадобятся вычисления, но ему придётся ждать освобождения CPU.

В таком случае лучше добавитьещё один сервер и запустить часть процессов на нём, чтобы у всех былодостаточно RAM и времени CPU.

Также возможенвсплеск использования вашего API: он мог «взорваться» по популярности, или какие‑то сервисы/боты начали его активно использовать. На такие случаи стоит иметь запас ресурсов.

Можно задатьцелевое значение, напримермежду 50% и 90% использования ресурсов. Скорее всего, именно эти вещи вы будете измерять и на их основе настраивать развёртывание.

Можно использовать простые инструменты вродеhtop, чтобы смотреть загрузку CPU и RAM на сервере или по процессам. Или более сложные распределённые системы мониторинга.

Резюме¶

Здесь вы прочитали о некоторых основных концепциях, которые, вероятно, стоит учитывать при выборе способа развёртывания приложения:

• Безопасность — HTTPS
• Запуск при старте
• Перезапуски
• Репликация (количество запущенных процессов)
• Память
• Предварительные шаги перед запуском

Понимание этих идей и того, как их применять, даст вам интуицию, необходимую для принятия решений при настройке и доработке ваших развёртываний. 🤓

В следующих разделах я приведу более конкретные примеры возможных стратегий. 🚀