Мега-Учебник Flask Глава 17: Развертывание на Linux (издание 2024)

Это семнадцатая часть серии мега-учебника Flask, в которой я собираюсь развернуть Microblog на сервере Linux.

Скрытый текст

• Глава 1: Привет, мир!

• Глава 2: Шаблоны

• Глава 3: Веб-формы

• Глава 4: База данных

• Глава 5: Логины пользователей

• Глава 6: Страница профиля и аватары

• Глава 7: Обработка ошибок

• Глава 8: Подписчики

• Глава 9: Разбивка на страницы

• Глава 10: Поддержка электронной почты

• Глава 11: Дизайн приложения

• Глава 12: Дата и время

• Глава 13: I18n и L10n

• Глава 14: Ajax

• Глава 15: Улучшенная структура приложения

• Глава 16: Полнотекстовый поиск

• Глава 17: Развертывание на Linux (Эта статья)

• Глава 18: Развертывание на Heroku

• Глава 19: Развертывание на контейнерах Docker

• Глава 20: Немного магии JavaScript

• Глава 21: Уведомления пользователей

• Глава 22: Фоновые задания

• Глава 23: Интерфейсы прикладного программирования (API)

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

Тема развертывания обширна, и по этой причине здесь невозможно охватить все возможные варианты. Эта глава посвящена изучению традиционных вариантов хостинга, и в качестве предметов я собираюсь использовать выделенный Linux-сервер под управлением Ubuntu, а также широко популярный мини-компьютер Raspberry Pi. Я рассмотрю другие варианты, такие как облачное и контейнерное развертывание, в последующих главах.

Ссылки на GitHub для этой главы: Browse, Zip, Diff.

Традиционный хостинг

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

Первый вопрос, который вам нужно задать, когда вы собираетесь развернуть свой собственный проект, - это где найти сервер. В наши дни существует множество экономичных услуг хостинга. Например, за 5 долларов в месяц, вы можете орендовать у Digital Ocean, Linode или Amazon Lightsail виртуализированный сервер Linux для проведения экспериментов по развертыванию (Linode и Digital Ocean предоставляют своим серверам начального уровня 1 ГБ оперативной памяти, в то время как Amazon предоставляет только 512 МБ). Если вы предпочитаете практиковаться в развертывании, не тратя никаких денег, то Vagrant и VirtualBox - это два инструмента, которые в совокупности позволяют вам создать виртуальный сервер, аналогичный платным, на вашем собственном компьютере.

Что касается выбора операционной системы, то с технической точки зрения это приложение может быть развернуто на любой из основных операционных систем, список которых включает большое разнообразие дистрибутивов Linux и BSD с открытым исходным кодом, а также коммерческие macOS и Microsoft Windows (macOS представляет собой гибрид открытого исходного кода и комерции, поскольку основана на Darwin, производной BSD с открытым исходным кодом).

Поскольку macOS и Windows являются настольными операционными системами, которые не оптимизированы для работы в качестве серверов, я собираюсь отбросить их как кандидатов. Выбор между операционной системой Linux или BSD во многом зависит от предпочтений, поэтому я собираюсь выбрать самую популярную из двух, то есть Linux. Что касается дистрибутивов Linux, я снова собираюсь выбирать по популярности и остановлюсь на Ubuntu.

Создание сервера Ubuntu

Если вы заинтересованы в выполнении этого развертывания вместе со мной, вам, очевидно, нужен сервер для работы. Я собираюсь порекомендовать вам два варианта приобретения сервера: платный и бесплатный. Если вы готовы потратить немного денег, вы можете завести учетную запись в Digital Ocean, Linode или Amazon Lightsail и создать виртуальный сервер Ubuntu с текущей версией долгосрочной поддержки (LTS), которая на момент написания этих строк имеет версию 22.04. Вам следует использовать самый маленький вариант сервера, который стоит около 5 долларов в месяц. Стоимость пропорциональна количеству часов работы сервера, поэтому, если вы создадите сервер, поиграете с ним несколько часов, а затем удалите, вы заплатите всего центы.

Бесплатная альтернатива основана на виртуальной машине, которую вы можете запускать на своем собственном компьютере. Чтобы использовать эту опцию, установите Vagrant и VirtualBox на свой компьютер, а затем создайте файл с именем Vagrantfile для описания спецификаций вашей виртуальной машины со следующим содержимым:

Vagrantfile: конфигурация Vagrant.

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/jammy64"
  config.vm.network "private_network", ip: "192.168.56.10"
  config.vm.provider "virtualbox" do |vb|
    vb.memory = "2048"
  end
end

Этот файл настраивает сервер Ubuntu 22.04 с 2 ГБ оперативной памяти, к которому вы сможете получить доступ с главного компьютера по IP-адресу 192.168.56.10. Чтобы создать сервер, выполните следующую команду:

$ vagrant up

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

Использование SSH - клиента

Наш сервер не имеет графического интерфейса, поэтому на нем не будет рабочего стола, как на вашем собственном компьютере. Я собираюсь подключиться к своему серверу через SSH-клиент и работать с ним через командную строку. Если вы используете Linux или Mac OS X, у вас, скорее всего, уже установлена OpenSSH. Если вы используете Microsoft Windows, Cygwin, Git и подсистема Windows для Linux предоставляют OpenSSH, поэтому вы можете установить любую из этих опций.

При использовании виртуального сервера от стороннего провайдера вам был предоставлен IP-адрес для него. Вы можете открыть терминальный сеанс с вашим совершенно новым сервером с помощью следующей команды:

$ ssh root@<server-ip-address>

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

Если вы используете виртуальную машину Vagrant, вы можете открыть сеанс терминала с помощью команды:

$ vagrant ssh

Если вы используете Windows и у вас виртуальная машина Vagrant, обратите внимание, что вам нужно будет запустить приведенную выше команду из командной оболочки, которая может вызывать команду ssh из OpenSSH.

Логины без пароля

Если вы используете виртуальную машину Vagrant, вы можете пропустить этот раздел, поскольку ваша виртуальная машина должным образом настроена на использование учетной записи с именем отличным от root, например vagrant или ubuntu, с автоматическим подключением без пароля, благодаря Vagrant.

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

Я собираюсь создать учетную запись пользователя с именем ubuntu (вы можете использовать другое имя, если предпочитаете). Чтобы создать эту учетную запись пользователя, войдите в учетную запись root вашего сервера, используя инструкции по ssh из предыдущего раздела, а затем введите следующие команды, чтобы создать пользователя, наделить его полномочиями sudo и, наконец, переключиться на него:

$ adduser --gecos "" ubuntu
$ usermod -aG sudo ubuntu
$ su ubuntu

Теперь я собираюсь настроить эту новую учетную запись ubuntu для использования аутентификации с открытым ключом , чтобы мы могли входить в систему без ввода пароля.

На мгновение оставьте сеанс терминала, открытый на вашем сервере, и запустите второй терминал на вашем локальном компьютере. Если вы используете Windows, это должен быть терминал, с которого у вас есть доступ к команде ssh, так что это, вероятно, будет bash или подобный ему среди не родных терминалов Windows. В этой сессии терминала, проверьте содержимое каталога ~/.ssh:

$ ls ~/.ssh
id_rsa  id_rsa.pub

Если в списке каталогов указаны файлы с именами id_rsa и id_rsa.pub , как указано выше, значит, у вас уже есть ключ. Если у вас нет этих двух файлов или если у вас вообще нет каталога ~/.ssh, то вам нужно создать свою пару ключей SSH, выполнив следующую команду, также входящую в набор инструментов OpenSSH:

$ ssh-keygen

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

После запуска этой команды у вас должны быть два файла, перечисленных выше. Файл id_rsa.pub является вашим открытым ключом, представляющий собой файл, который вы передадите третьим лицам для вашей идентификации. Файл id_rsa - это ваш закрытый ключ, которым не следует никому делиться.

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

$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCjw....F8Xv4f/0+7WT miguel@miguelspc

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

$ echo <paste-your-key-here> >> ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys

Теперь должен работать логин без пароля. Идея заключается в том, что ssh на вашем компьютере идентифицирует себя перед сервером путем выполнения криптографической операции, для которой требуется закрытый ключ. Затем сервер проверяет правильность операции, используя ваш открытый ключ.

Теперь вы можете выйти из своего сеанса ubuntu , а затем из сеанса root , а затем попытаться войти непосредственно в учетную запись ubuntu с помощью:

$ ssh ubuntu@<server-ip-address>

На этот раз вам не придется вводить пароль!

Защита вашего сервера

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

Первое изменение, которое я собираюсь внести, - это отключить вход в систему под пользователем root через SSH. Теперь у вас есть доступ к учетной записи ubuntu без пароля, и вы можете запускать команды администратора из этой учетной записи через sudo, так что на самом деле нет необходимости предоставлять учетную запись root для удаленного подключения. Чтобы отключить вход с правами root, вам необходимо отредактировать файл /etc/ssh/sshd_config на вашем сервере. Вероятно, на вашем сервере установлены текстовые редакторы vi и nano, которые вы можете использовать для редактирования файлов (если вы не знакомы ни с одним из них, попробуйте сначала nano). Вам нужно будет добавить префикс sudo в вызов вашего редактора, поскольку конфигурация SSH недоступна обычным пользователям (т.е. sudo vi /etc/ssh/sshd_config). Вам нужно изменить одну строку в этом файле.:

/etc/ssh / sshd_config: Отключение входа под пользователем root.

PermitRootLogin no

Обратите внимание, что для внесения этого изменения вам нужно найти строку, начинающуюся с PermitRootLogin, и изменить значение, каким бы оно ни было на вашем сервере, на no.

Следующее изменение внесено в тот же файл. Теперь я собираюсь отключить вход с паролем для всех учетных записей. У вас настроен вход без пароля, поэтому нет необходимости разрешать пароли вообще. Если вы нервничаете из-за полного отключения паролей, вы можете пропустить это изменение, но для производственного сервера это хорошая идея, поскольку злоумышленники постоянно пробуют случайные имена учетных записей и пароли на всех серверах, надеясь на удачу. Чтобы отключить ввод пароля для входа в систему, измените следующую строку в /etc/ssh /sshd_config:

/etc/ssh / sshd_config: Отключение ввода пароля для входа в систему.

PasswordAuthentication no

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

$ sudo service ssh restart

Третье изменение, которое я собираюсь внести, - это установить брандмауэр. Это программное обеспечение, которое блокирует доступ к серверу через любые порты, которые явно не включены:

$ sudo apt-get install -y ufw
$ sudo ufw allow ssh
$ sudo ufw allow http
$ sudo ufw allow 443/tcp
$ sudo ufw --force enable
$ sudo ufw status

Эти команды устанавливают ufw, несложный брандмауэр, и настраивают его так, чтобы разрешать внешний трафик только через порты 22 (ssh), 80 (http) и 443 (https). Любые другие порты будут запрещены.

Установка базовых зависимостей

Если вы последовали моему совету и подготовили свой сервер к выпуску Ubuntu 20.04, то у вас есть система, которая поставляется с полной поддержкой Python 3.8, так что это выпуск, который я собираюсь использовать для развертывания.

Базовый интерпретатор Python, вероятно, предварительно установлен на вашем сервере, но есть некоторые дополнительные пакеты, которых, скорее всего, нет, а также есть несколько других пакетов вне Python, которые будут полезны при создании надежного развертывания, готового к производству. Для сервера баз данных я собираюсь переключиться с SQLite на MySQL. Пакет postfix - это агент передачи почты, который я буду использовать для отправки электронных писем. Инструмент супервизора будет отслеживать процесс работы сервера Flask и автоматически перезапускать его, если он когда-либо выйдет из строя, а также при перезагрузке сервера. Сервер nginx будет принимать все запросы, поступающие из внешнего мира, и пересылать их приложению. Наконец, я собираюсь использовать git в качестве предпочтительного инструмента для загрузки приложения непосредственно из его репозитория git.

$ sudo apt-get -y update
$ sudo apt-get -y install python3 python3-venv python3-dev
$ sudo apt-get -y install mysql-server postfix supervisor nginx git

Эти установки выполняются в основном без ввода дополнительной конфигурации. В зависимости от устанавливаемой вами версии Ubuntu может появиться запрос на перезапуск служб, который вы можете принять с параметрами по умолчанию. Во время выполнения третьей инструкции по установке вам будет задана пара вопросов, касающихся установки пакета postfix, которые вы также можете принять с ответами по умолчанию.

Обратите внимание, что для этого развертывания я решил не устанавливать Elasticsearch. Для этой службы требуется большой объем оперативной памяти, поэтому она жизнеспособна, только если у вас большой сервер с объемом оперативной памяти более 2 ГБ. Чтобы избежать проблем с нехваткой памяти на сервере, я не буду использовать функцию поиска. Если у вас достаточно большой сервер, вы можете загрузить официальный пакет .deb с сайта Elasticsearch и следовать инструкциям по установке, чтобы добавить его на свой сервер.

Я должен также отметить, что установка postfix по умолчанию, вероятно, недостаточна для отправки электронной почты в производственной среде. Чтобы избежать спама и вредоносных электронных писем, многие серверы требуют, чтобы сервер-отправитель идентифицировал себя с помощью расширений безопасности, что означает, что, по крайней мере, у вас должно быть доменное имя, связанное с вашим сервером. Если вы хотите узнать, как полностью настроить почтовый сервер, чтобы он прошел стандартные тесты безопасности, ознакомьтесь со следующими руководствами Digital Ocean:

• Настройка Postfix

• Добавление записи SPF

• Установка и настройка DKIM

Установка приложения

Теперь я собираюсь использовать git для загрузки исходного кода микроблога из моего репозитория GitHub. Я рекомендую вам прочитать git для начинающих, если вы не знакомы с системой управления версиями git.

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

$ git clone https://github.com/miguelgrinberg/microblog
$ cd microblog
$ git checkout v0.17

Этот код устанавливается на ваш сервер и синхронизируется с этой главой. Если вы храните свою версию кода из этого туториала в своем собственном репозитории git, вы можете изменить URL репозитория на свой, и в этом случае вы можете пропустить команду git checkout.

Теперь мне нужно создать виртуальную среду и заполнить ее всеми зависимостями пакетов, которые я удобно сохранил в файле requirements.txt в Главе 15:

$ python3 -m venv venv
$ source venv/bin/activate
(venv) $ pip install -r requirements.txt

В дополнение к общим требованиям в файле requirements.txt я собираюсь использовать три пакета, специфичных для данного производственного развертывания, поэтому они не включены в файл общих требований. Пакет gunicorn представляет собой производственный веб-сервер для приложений Python. Пакет pymysql содержит драйвер MySQL, который позволяет SQLAlchemy работать с базами данных MySQL. Пакет cryptography используется пакетом pymsql для аутентификации на сервере баз данных MySQL.

(venv) $ pip install gunicorn pymysql cryptography

Мне нужно создать файл .env со всеми необходимыми переменными среды:

/home/ubuntu/microblog/.env: Настройка среды.

SECRET_KEY=52cb883e323b48d78a0a36e8e951ba4a
MAIL_SERVER=localhost
MAIL_PORT=25
DATABASE_URL=mysql+pymysql://microblog:<db-password>@localhost:3306/microblog
MS_TRANSLATOR_KEY=<your-translator-key-here>

Этот файл .env в основном похож на пример, который я показал в Глава 15, но я использовал случайную строку для SECRET_KEY. Здесь вы должны сгенерировать свой собственный секретный ключ. Вы можете использовать следующую команду:

python3 -c "import uuid; print(uuid.uuid4().hex)"

Для переменной DATABASE_URL я определил URL-адрес MySQL. Я покажу вам, как настроить базу данных в следующем разделе.

Мне нужно установить переменную окружения FLASK_APP в качестве точки входа приложения, чтобы включить работу команды flask . Если у вас нет файла .flaskenv в репозитории вашего проекта, значит, пришло время добавить его. Вы можете подтвердить, что переменная FLASK_APP настроена, выполнив команду flask --help. Если в справочном сообщении отображается команда translate, добавленная приложением, означает, что приложение найдено.

И теперь, когда команда flask работает, я могу скомпилировать языковые переводы:

(venv) $ flask translate compile

Настройка MySQL

База данных SQLite, которую я использовал во время разработки, отлично подходит для простых приложений, но при развертывании полноценного веб-сервера, которому потенциально может потребоваться обрабатывать несколько запросов одновременно, лучше использовать более надежную базу данных. По этой причине я собираюсь настроить базу данных MySQL, которую я назову microblog.

Для управления сервером базы данных я собираюсь использовать команду mysql , которая должна быть уже установлена на вашем сервере:

$ sudo mysql -u root
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 8.0.25-0ubuntu0.20.04.1 (Ubuntu)

Copyright (c) 2000, 2021, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

Обратите внимание, что вам нужно будет использовать sudo для доступа к пользователю root MySQL из учетной записи администратора.

Это команды, которые создают новую базу данных с именем microblog и пользователя с тем же именем, который имеет к ней полный доступ:

mysql> create database microblog character set utf8 collate utf8_bin;
mysql> create user 'microblog'@'localhost' identified by '<db-password>';
mysql> grant all privileges on microblog.* to 'microblog'@'localhost';
mysql> flush privileges;
mysql> quit;

Вам нужно будет заменить <db-password> паролем по вашему выбору. Пароль, который вы выбираете здесь, должен соответствовать паролю, который вы указали в переменной DATABASE_URL в файле .env .

Если ваша конфигурация базы данных верна, теперь вы должны иметь возможность запускать миграции базы данных, которые создают все таблицы:

(venv) $ flask db upgrade

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

Настройка Gunicorn и Supervisor

Когда вы запускаете сервер с помощью flask run, вы используете веб-сервер, который поставляется вместе с Flask. Этот сервер очень полезен при разработке, но его не стоит использовать в качестве производственного сервера, поскольку он не был создан с учетом производительности и надежности. Вместо сервера разработки Flask для этого развертывания я решил использовать Gunicorn, который также является веб-сервером на чистом Python, но, в отличие от Flask, это надежный производственный сервер, которым пользуется множество людей, и в то же время его очень легко настроить.

Чтобы запустить микроблог в Gunicorn, вы можете использовать следующую команду:

(venv) $ gunicorn -b localhost:8000 -w 4 microblog:app

Опция -b указывает Gunicorn, где прослушивать запросы, которые я настроил на внутренний сетевой интерфейс через порт 8000. Обычно хорошей идеей является запуск веб-приложений на Python без внешнего доступа, а затем иметь очень быстрый веб-сервер, оптимизированный для обслуживания статических файлов, принимающих все запросы от клиентов. Этот быстрый веб-сервер будет обслуживать статические файлы напрямую и перенаправлять любые запросы, предназначенные для приложения, на внутренний сервер. В следующем разделе я покажу вам, как настроить nginx в качестве общедоступного сервера.

Параметр -w определяет, сколько будет рабочих процессов Gunicorn. Наличие четырех рабочих процессов позволяет приложению обрабатывать до четырех клиентов одновременно, чего для веб-приложения обычно достаточно для обработки приличного количества клиентов, поскольку не все из них постоянно запрашивают контент. В зависимости от объема оперативной памяти вашего сервера вам может потребоваться отрегулировать количество рабочих процессов, чтобы у вас не заканчивалась память.

Аргумент microblog:app сообщает Gunicorn, как загрузить экземпляр приложения. Имя перед двоеточием обозначает модуль, содержащий приложение, которое для этого приложения является microblog.py. Имя после двоеточия - это имя экземпляра приложения.

Хотя Gunicorn очень прост в настройке, запуск сервера из командной строки на самом деле не является хорошим решением для производственного сервера. Что я хочу сделать, так это запустить сервер в фоновом режиме и постоянно контролировать его, потому что, если по какой-либо причине сервер выйдет из строя, я хочу убедиться, что заново запущенный сервер автоматически займет его место. И я также хочу убедиться, что при перезагрузке компьютера сервер запускается автоматически при запуске, без необходимости входить в систему и запускать все самому. Я собираюсь использовать пакет supervisor, который я установил выше для этого.

Утилита supervisor использует файлы конфигурации, которые сообщают ей, какие программы следует отслеживать и как перезапустить их при необходимости. Файлы конфигурации должны храниться в /etc/supervisor/conf.d. Вот файл конфигурации для Microblog, который я собираюсь назвать microblog.conf:

/etc/supervisor/conf.d/microblog.conf: Настройка супервизора.

[program:microblog]
command=/home/ubuntu/microblog/venv/bin/gunicorn -b localhost:8000 -w 4 microblog:app
directory=/home/ubuntu/microblog
user=ubuntu
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true

В настройках command, directory и user указано, как запустить приложение. Параметры autostart и autorestart настраивают автоматический перезапуск из-за запуска компьютера или сбоев. Параметры stopasgroup и killasgroup гарантируют, что, когда супервизору необходимо остановить приложение для его перезапуска, он также достигает дочерних процессов процесса верхнего уровня Gunicorn.

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

sudo supervisorctl reload

И точно так же веб-сервер Gunicorn должен быть запущен и контролироваться!

Настройка Nginx

Сервер для микроблога на базе Gunicorn теперь работает в частном порядке на порту 8000. Что мне нужно сделать сейчас, чтобы открыть приложение внешнему миру, так это включить мой общедоступный веб-сервер на портах 80 и 443, двух портах, которые я открыл на брандмауэре, для обработки веб-трафика приложения.

Я хочу, чтобы это было безопасное развертывание, поэтому я собираюсь настроить порт 80 для пересылки всего трафика на порт 443, который будет зашифрован. Итак, я собираюсь начать с создания SSL-сертификата. Сейчас я собираюсь создать самозаверяющий SSL-сертификат, который подходит для тестирования всего, но не подходит для реального развертывания, потому что веб-браузеры будут предупреждать пользователей, что сертификат не был выдан доверенным центром сертификации. Команда для создания SSL - сертификата для microblog такова:

$ mkdir certs
$ openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 -keyout certs/key.pem -out certs/cert.pem

Команда запросит у вас некоторую информацию о вашем приложении и о вас самих. Эта информация будет включена в SSL-сертификат, и веб-браузеры будут показывать ее пользователям, если они захотят ее просмотреть. Результатом выполнения приведенной выше команды будут два файла с именами key.pem и cert.pem, которые я поместил в подкаталог certs корневого каталога microblog.

Чтобы веб-сайт обслуживался nginx, вам необходимо написать для него файл конфигурации. В большинстве установок nginx этот файл должен находиться в каталоге/etc/nginx/sites-available. Ниже вы можете увидеть файл конфигурации nginx для Microblog, который находится в /etc/nginx/sites-available/microblog:

/etc/nginx/sites-available/microblog: Настройка Nginx.

server {
    # listen on port 80 (http)
    listen 80;
    server_name _;
    location / {
        # redirect any requests to the same URL but on https
        return 301 https://$host$request_uri;
    }
}
server {
    # listen on port 443 (https)
    listen 443 ssl;
    server_name _;

    # location of the self-signed SSL certificate
    ssl_certificate /home/ubuntu/microblog/certs/cert.pem;
    ssl_certificate_key /home/ubuntu/microblog/certs/key.pem;

    # write access and error logs to /var/log
    access_log /var/log/microblog_access.log;
    error_log /var/log/microblog_error.log;

    location / {
        # forward application requests to the gunicorn server
        proxy_pass http://localhost:8000;
        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location /static {
        # handle static files directly, without forwarding to the application
        alias /home/ubuntu/microblog/app/static;
        expires 30d;
    }
}

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

Веб-сайт теперь настроен, но еще не включен. Чтобы включить его, необходимо создать ссылку на этот файл в каталоге /etc/nginx /sites-enabled . Nginx поставляется с включенным тестовым сайтом, который мне на самом деле не нужен, поэтому я собираюсь начать с его удаления:

$ sudo rm /etc/nginx/sites-enabled/default

Теперь я могу создать ссылку на конфигурацию микроблога:

sudo ln -s /etc/nginx/sites-available/microblog /etc/nginx/sites-enabled/microblog

После добавления этого файла нам нужно сообщить nginx перезагрузить конфигурацию:

$ sudo service nginx reload

А теперь приложение должно быть развернуто. В своем веб-браузере вы можете ввести IP-адрес своего сервера (или 192.168.56.10, если вы используете виртуальную машину Vagrant), и он подключится к приложению. Поскольку вы используете самозаверяющий сертификат, вы получите предупреждение от веб-браузера, которое вам придется отклонить.

После завершения развертывания с использованием приведенных выше инструкций для ваших собственных проектов я настоятельно рекомендую вам заменить самозаверяющий сертификат на настоящий, чтобы браузер не предупреждал ваших пользователей о вашем сайте. Для этого вам сначала нужно будет приобрести доменное имя и настроить его так, чтобы оно указывало на IP-адрес вашего сервера. Как только у вас будет домен, вы можете запросить бесплатный Let's Encrypt SSL-сертификат. В своем блоге я написал подробную статью о том, как Запустить ваше приложение Flask по протоколу HTTPS.

Развертывание обновлений приложений

Последняя тема, которую я хочу обсудить относительно развертывания на базе Linux, - это то, как обрабатывать обновления приложений. Исходный код приложения устанавливается на сервер через git, поэтому всякий раз, когда вы захотите обновить свое приложение до последней версии, вы можете просто запустить git pull для загрузки новых коммитов, которые были сделаны с момента предыдущего развертывания.

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

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

(venv) $ git pull                              # download the new version
(venv) $ sudo supervisorctl stop microblog     # stop the current server
(venv) $ flask db upgrade                      # upgrade the database
(venv) $ flask translate compile               # upgrade the translations
(venv) $ sudo supervisorctl start microblog    # start a new server

Хостинг Raspberry Pi

Raspberry Pi - это недорогой революционный маленький компьютер под управлением Linux с очень низким энергопотреблением, поэтому это идеальное устройство для размещения домашнего веб-сервера, который может быть подключен к Сети 24/7, не подключая ваш настольный компьютер или ноутбук. Существует несколько дистрибутивов Linux, которые работают на Raspberry Pi. Мой выбор - Raspberry Pi OS, которая является официальным дистрибутивом от Raspberry Pi Foundation.

Чтобы подготовить Raspberry Pi, я собираюсь установить свежую версию Raspberry Pi OS. Я буду использовать облегченную версию, потому что мне не нужен пользовательский интерфейс для рабочего стола. Вы можете найти последнюю версию Raspberry Pi OS на их странице операционных систем.

Образ Raspberry Pi OS необходимо установить на SD-карту, которую затем подключить к Raspberry Pi, чтобы она могла загружаться с нее. Инструкции для копирования образа Raspberry Pi OS на SD-карту в Windows, Mac ОС X и Linux доступны на Сайте Raspberry Pi .

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

Как и Ubuntu, Raspberry Pi OS является производной от Debian, поэтому приведенные выше инструкции для Ubuntu Linux по большей части работают так же хорошо и для Raspberry Pi. Однако вы можете пропустить некоторые шаги, если планируете запускать небольшое приложение в своей домашней сети без внешнего доступа. Например, вам может не понадобиться брандмауэр или логины без пароля. И вы можете захотеть использовать SQLite вместо MySQL на таком маленьком компьютере. Вы можете отказаться от использования nginx и просто использовать сервер Gunicorn, прослушивающий запросы от клиентов напрямую. Вероятно, вам понадобится всего один или два рабочих процесса Gunicorn. Служба супервизора полезна для обеспечения постоянной работы приложения, поэтому я рекомендую вам использовать ее и на Raspberry Pi.

Следующая глава =>