Д. Устранение неполадок при развертывании
Развертывание приложения доставляет огромное удовольствие, когда выполняется успешно, особенно в первый раз. Но в процессе может возникнуть множество проблем, и, к сожалению, некоторые из них бывает сложно выявить и устранить. В этом приложении вы узнаете о современных подходах к развертыванию и эффективных способах устранения неполадок в процессе развертывания, когда что-то идет не так, как хочется.
Если дополнительной информации в этом приложении недостаточно для решения проблем, возникающих в процессе развертывания, то обратитесь к ресурсам, указанным на сайте https://ehmatthes.github.io/pcc_3e; их содержимое почти наверняка поможет вам успешно выполнить развертывание.
Основы развертывания приложений
Когда вы пытаетесь устранить неполадки в конкретной ситуации развертывания, полезно иметь четкое представление о том, как устроено типичное развертывание. Под развертыванием (deployment) понимается процесс копирования проекта, работающего в вашей локальной системе, на удаленный сервер таким образом, чтобы проект мог обрабатывать запросы любого пользователя в Интернете. Удаленная среда отличается от локальной системы несколькими важными моментами: скорее всего, операционная система (ОС) будет не такой, как у вас, и, по всей видимости, это один из множества виртуальных серверов, развернутых на одном аппаратном сервере.
Когда вы разворачиваете (копируете, push) проект на удаленный сервер, необходимо выполнить следующие действия.
• Создать виртуальный сервер на компьютере в центре обработки данных.
• Установить соединение между локальной системой и удаленным сервером.
• Скопировать код проекта на удаленный сервер.
• Определить зависимости проекта и установить их на удаленном сервере.
• Настроить базу данных (БД) и выполнить все необходимые миграции.
• Скопировать статические файлы (CSS, JavaScript и мультимедийные) в место, где их можно будет эффективно обслуживать.
• Запустить сервер для обработки входящих запросов.
• Маршрутизировать входящие запросы в проект, как только он будет готов к их обработке.
Если учесть все, что касается развертывания, то неудивительно, что процесс часто оказывается неудачным. К счастью, поняв его суть, вы с большой долей вероятности сможете определить, что именно пошло не так. И тогда, возможно, сумеете найти решение, которое сделает следующую попытку развертывания успешной.
Вы можете разрабатывать проекты локально в одной ОС, а публиковать на сервере под управлением другой. Важно знать, в какой системе вы разворачиваете проект, поскольку это поможет в устранении неполадок. На момент написания этой книги типичный удаленный сервер на Platform.sh работал под управлением операционной системы Debian Linux; большинство удаленных серверов работают на базе Linux.
Устранение распространенных неполадок
Некоторые шаги по устранению неполадок характерны для той или иной ОС, и мы разберем их чуть позже. Сначала рассмотрим универсальные приемы, которые следует попробовать применить при устранении неполадок в развертывании.
Лучший источник информации о проблеме — вывод, полученный во время попытки развертывания. Эти данные могут напугать неопытных пользователей; они могут выглядеть крайне сложными технически, и их обычно очень много. Не спешите впадать в уныние; вам не нужно понимать все, что написано в выходных данных. При просмотре журнала вы преследуете две цели: определить успешные и неуспешные шаги развертывания. Если справитесь с этой задачей, то сможете понять, что нужно изменить в вашем проекте или процессе развертывания, чтобы следующая попытка увенчалась успехом.
Следуйте инструкциям на экране
Иногда платформа, на которой вы разворачиваете проект, выдает сообщение с четким предложением, как решить проблему. Например, показанное ниже сообщение вы увидите, если создадите проект Platform.sh до инициализации репозитория Git, а затем попытаетесь развернуть проект:
$ platform push
❶ Enter a number to choose a project:
[0] ll_project (votohz445ljyg)
> 0
❷ [RootNotFoundException]
Project root not found. This can only be run from inside a project directory.
❸ To set the project for this Git repository, run:
platform project:set-remote [id]
Мы пытаемся развернуть проект, но локальный проект еще не связан с удаленным. Поэтому в CLI Platform.sh появляется запрос, какой удаленный проект мы хотим развернуть ❶. Мы указываем 0, чтобы выбрать единственный проект из списка. Но возникает ошибка RootNotFoundException ❷. Так происходит потому, что Platform.sh при проверке локального проекта ищет каталог .git, чтобы связать локальный проект с удаленным. В данном случае, поскольку при создании удаленного проекта каталога .git не существует, соединение так и не было установлено. CLI предлагает с помощью команды project:set-remote указать удаленный проект, который должен быть связан с локальным ❸.
Попробуем воспользоваться этим предложением:
$ platform project:set-remote votohz445ljyg
Setting the remote project for this repository to: ll_project (votohz445ljyg)
The remote project for this repository is
now set to: ll_project (votohz445ljyg)
В предыдущем выводе CLI был указан идентификатор удаленного проекта, votohz4451jyg. Поэтому мы дополняем предложенную команду, указав этот идентификатор, и CLI устанавливает соединение между локальным и удаленным проектами.
Теперь снова попробуем развернуть проект:
$ platform push
Are you sure you want to push to the main (production) branch? [Y/n] y
Pushing HEAD to the existing environment main
--пропуск--
Развертывание прошло успешно; следование инструкциям на экране помогло.
С осторожностью выполняйте команды, предназначение которых понимаете не до конца. Однако если у вас есть веские причины считать, что команда недеструктивна, и если вы доверяете источнику рекомендаций, то, думаю, разумно воспользоваться предложениями, отображающимися на экране.
ПРИМЕЧАНИЕ
Не забывайте, что существуют злоумышленники, способные посоветовать вам выполнить команды, которые выведут вашу систему из строя или подвергнут ее удаленной эксплуатации. Следование рекомендациям инструмента, предоставленного доверенной компанией или организацией, — это одно, а выполнение рекомендаций случайных людей в Интернете — другое. В любом случае, когда имеете дело с удаленными подключениями, действуйте с осторожностью.
Читайте журнал событий
Как уже говорилось, системный вывод, который отображается при выполнении таких команд, как platform push, может быть как информативным, так и поначалу совершенно непонятным. Ознакомьтесь с показанным ниже фрагментом журнала, созданным в одном из случаев выполнения команды platform push, и попробуйте выявить проблему:
--пропуск--
Collecting soupsieve==2.3.2.post1
Using cached soupsieve-2.3.2.post1-py3-none-any.whl (37 kB)
Collecting sqlparse==0.4.2
Using cached sqlparse-0.4.2-py3-none-any.whl (42 kB)
Installing collected packages: platformshconfig, sqlparse,...
Successfully installed Django-4.1 asgiref-3.5.2 beautifulsoup4-4.11.1...
W: ERROR: Could not find a version that satisfies the requirement gunicorrn
W: ERROR: No matching distribution found for gunicorrn
130 static files copied to '/app/static'.
Executing pre-flight checks...
--пропуск--
Если попытка развертывания не удалась, то рекомендуется просмотреть системный журнал и найти в нем нечто похожее на предупреждения или ошибки. Предупреждения — довольно распространенное явление; часто это сообщения о предстоящих изменениях в зависимостях проекта, позволяющие разработчикам решить проблемы до того, как они приведут к реальным сбоям.
Успешный процесс развертывания может сопровождаться предупреждениями, но не ошибками! В приведенном выше случае Platform.sh не смог соблюсти требование gunicorrn. Это опечатка, закравшаяся в файл requirements_remote.txt, которая должна была интерпретироваться как gunicorn (с одной буквой r). Не всегда легко обнаружить источник проблемы в журнале, особенно если проблема вызывает каскад ошибок и предупреждений. Как и при чтении трассировки в локальной системе, стоит внимательно изучить первые несколько ошибок в списке, а также последние. Большинство ошибок между ними — это конфликты внутренних пакетов из-за нештатных ситуаций и передача сообщений об ошибке другим внутренним пакетам. Фактическая ошибка, которую мы можем исправить, обычно значится одной из первых или последних в списке.
Иногда вы сможете обнаружить ошибку, а иногда не будете иметь ни малейшего представления, что означает вывод. Попробовать разобраться в нем, конечно, стоит, и анализ журнала с последующей успешной диагностикой проблемы приносит огромное удовлетворение. Проводя больше времени за просмотром журнала, вы сможете лучше выявлять наиболее значимую для вас информацию.
Устранение неполадок, специфичных для ОС
Вы можете разрабатывать приложения в любой операционной системе, которая вам по душе, и разворачивать на серверах любых хостинг-провайдеров. Инструменты для разворачивания проектов развиты настолько, что позволяют корректировать ваши проекты для успешной работы в любой удаленной системе. Однако могут возникнуть некоторые проблемы, связанные с той или иной ОС.
В процессе развертывания на платформе Platform.sh одним из наиболее вероятных источников проблем служит установка CLI. Взгляните на следующую команду:
$ curl -fsS https://platform.sh/cli/installer | php
Команда начинается с имени curl, инструмента, позволяющего запрашивать в терминале удаленные ресурсы, доступ к которым осуществляется с помощью URL. В данном случае этот инструмент используется для скачивания программы установки CLI с сервера Platform.sh. Сочетание символов -fsS в команде представляет собой набор флагов, которые изменяют работу инструмента curl. Флаг f дает curl указание подавлять большинство сообщений об ошибках, чтобы программа установки CLI могла обрабатывать их самостоятельно, а не сообщать вам обо всех. Флаг s определяет параметр тихого запуска в curl и позволяет программе установки CLI решать, какую информацию выводить в терминале. Флаг S дает curl указание выводить сообщение об ошибке, если команда в целом не была выполнена. Благодаря флагу | php в конце команды ваша система получает указание запустить скачанный файл установщика с помощью интерпретатора PHP, поскольку инструментарий CLI Platform.sh написан на PHP.
Таким образом, для установки CLI Platform.sh в вашей системе необходимы инструменты curl и PHP. Чтобы использовать CLI, вам также понадобятся Git и терминал, в котором можно выполнять команды Bash. Это язык, доступный в большинстве серверных сред. В большинстве современных систем достаточно пространства для установки нескольких подобных инструментов.
Материал следующих подразделов поможет вам разобраться с требованиями для вашей ОС. Если у вас еще не установлен Git, то ознакомьтесь с инструкциями по работе с ним, изложенными в приложении Г, а затем перейдите к подразделу в этом приложении, соответствующему вашей операционной системе.
ПРИМЕЧАНИЕ
Отличный ресурс для изучения терминальных команд, подобных показанной выше, расположен на https://explainshell.com. Укажите изучаемую команду — и сайт отобразит документацию по всем ее компонентам. Попробуйте найти информацию по команде, используемой для установки CLI Platform.sh.
Развертывание из Windows
В последние годы операционная система Windows вновь обрела популярность среди программистов. В нее интегрировано множество различных компонентов для других операционных систем, благодаря чему пользователи получили ряд возможностей для локальной разработки и взаимодействия с удаленными системами.
Одна из наиболее серьезных трудностей при развертывании из Windows заключается в том, что базовая операционная система Windows не похожа на систему Linux, которая используется на удаленном сервере. В базовой системе Windows другой набор инструментов и языков, поэтому для развертывания проектов из нее нужно выбрать способ интеграции Linux-инструментов в локальную среду.
Подсистема Windows для Linux
Один из популярных подходов — использование подсистемы Windows для Linux (Windows Subsystem for Linux, WSL), среды, которая позволяет запускать Linux непосредственно в Windows. Если у вас настроена подсистема WSL, то использовать CLI Platform.sh в Windows будет так же просто, как и в Linux. CLI не сможет определить, что запущен в Windows; он обнаружит только среду Linux, в которой вы его используете.
Настройка WSL состоит из двух этапов: сначала вы устанавливаете подсистему WSL, а затем выбираете дистрибутив Linux для развертывания в среде WSL. Тема настройки среды WSL выходит за рамки этой книги; если она вам интересна, то обратитесь к документации по адресу https://learn.microsoft.com/ru-ru/windows/wsl/about. После установки WSL вы можете следовать инструкциям для операционной системы Linux, изложенным в этом приложении, чтобы продолжить развертывание.
Git Bash
Другой подход к формированию локального окружения, из которого можно развернуть систему, касается Git Bash, терминальной среды, совместимой с Bash, но работающей в Windows. Git Bash устанавливается вместе с Git, с помощью дистрибутива, доступного на сайте https://git-scm.com. Этот подход вполне рабочий, но не так удобен, как в случае с WSL. Для выполнения некоторых шагов вам придется использовать терминал Windows, а для других — терминал Git Bash.
Сначала вам нужно установить PHP. Вы можете сделать это с помощью XAMPP, пакета, который, помимо PHP, содержит несколько других инструментов для разработчиков. Чтобы скачать XAMPP для Windows, перейдите по адресу https://apachefriends.org. Запустите программу установки и, если увидите предупреждение об ограничениях контроля учетных записей пользователей (UAC), нажмите кнопку OK. Примите все рекомендации мастера установки по умолчанию и установите программу.
После завершения установки необходимо добавить PHP в системное окружение (Path); так операционная система Windows будет знать, где искать PHP при его запуске. В строке поиска меню Start (Пуск) введите path (в русской версии — переменн. — Примеч. пер.) и выберите пункт Edit the System Environment Variables (Изменение системных переменных среды); в появившемся диалоговом окне нажмите кнопку Environment Variables (Переменные среды). Выделите переменную Path; нажмите кнопку Edit (Изменить). В появившемся диалоговом окне нажмите кнопку New (Создать), чтобы добавить новый путь в список. Если вы использовали путь по умолчанию в процессе установки программы XAMPP, то добавьте строку C:\xampp\php в появившемся поле, затем нажмите кнопку OK. Теперь закройте все системные диалоговые окна, которые были открыты.
Выполнив эти требования, вы можете установить CLI Platform.sh. Для этого вам понадобится терминал Windows с правами администратора; введите команду cmd в строке поиска меню Start (Пуск) и, щелкнув на пункте Command Prompt (Командная строка) правой кнопкой мыши, выберите пункт Run as administrator (Запуск от имени администратора) в контекстном меню. В открывшемся терминале введите следующую команду:
> curl -fsS https://platform.sh/cli/installer | php
Так вы сможете установить CLI Platform.sh, как было описано ранее.
Итак, вы можете работать в Git Bash. Чтобы открыть его терминал, в меню Start (Пуск) найдите приложение Git Bash и щелкните на его ярлыке кнопкой мыши; у вас должно открыться окно терминала. В этом терминале вы можете использовать команды, традиционные как для Linux (например, ls), так и для Windows (к примеру, dir). Чтобы убедиться в успешности установки, выполните команду platform list. Вы должны увидеть список всех команд CLI Platform.sh. С этого момента все операции по развертыванию выполняйте с помощью CLI Platform.sh в окне терминала Git Bash.
Развертывание из macOS
Операционная система macOS отличается от Linux, но обе системы были разработаны на схожих алгоритмах Unix. Благодаря этому многие команды и рабочие процессы, которые вы используете в macOS, будут работать и в удаленной серверной среде. Возможно, вам потребуется установить дополнительные компоненты для разработчиков, чтобы все необходимые инструменты были доступны в вашей локальной среде macOS. Если в процессе работы вам будет предложено установить инструменты разработчика командной строки (command line developer tools), то нажмите кнопку Install (Установить), чтобы подтвердить установку.
Наиболее распространенная проблема при установке CLI Platform.sh заключается в отсутствии в системе PHP. Если вы видите сообщение о том, что команда php не найдена, то вам нужно установить PHP. Один из самых простых способов сделать это — использовать менеджер пакетов Homebrew, который упрощает установку множества пакетов, требующихся программистам. Если у вас еще не установлена программа Homebrew, то посетите сайт https://brew.sh и следуйте инструкциям по ее установке.
После установки Homebrew используйте следующую команду для установки PHP:
$ brew install php
Через некоторое время, когда установка завершится, вы сможете успешно установить CLI Platform.sh.
Развертывание из Linux
Поскольку большинство серверных сред функционируют под управлением операционной системы Linux, у вас не должно возникнуть особых проблем с установкой и использованием Platform.sh CLI. В процессе установки CLI в свежеразвернутой системе типа Ubuntu вы увидите уведомления о том, какие именно пакеты вам нужны:
$ curl -fsS https://platform.sh/cli/installer | php
Command 'curl' not found, but can be installed with:
sudo apt install curl
Command 'php' not found, but can be installed with:
sudo apt install php-cli
В вашем случае будет больше информации о других пакетах, которые нужно установить, а также данные о версии. Показанная ниже команда установит curl и PHP:
$ sudo apt install curl php-cli
После этого команда установки CLI Platform.sh должна завершиться успешно. Поскольку ваша локальная среда очень похожа на большинство Linux-сред хостинг-провайдеров, многие моменты, касающиеся работы в терминале, будут идентичны и в удаленной среде.
Другие подходы к развертыванию
Если платформа Platform.sh по каким-то причинам вам не подходит или вы хотите попробовать другой подход, то существует множество хостинговых компаний, из которых можно выбрать наиболее подходящую. Одни хостинг-платформы функционируют идентично процессу, описанному в главе 20, а другие используют совершенно иной подход, описанный в начале этого приложения.
• Система Platform.sh позволяет выполнять шаги в браузере вместо CLI. Если вам больше нравится графический интерфейс, чем терминальный, то вы можете выбрать этот подход.
• Некоторые хостинг-провайдеры предлагают взаимодействие как через CLI, так и через браузер. В ряде случаев в браузере запускается специальный терминал, так что вам не нужно ничего устанавливать на свой компьютер.
• Некоторые провайдеры позволяют размещать проекты на сайтах типа GitHub, а затем подключать репозитории GitHub к хостингу. После этого провайдер разворачивает ваш код из GitHub, а не требует от вас выгрузить код из локальной системы на сервер. На сайте Platform.sh тоже поддерживается такая схема работы.
• Некоторые провайдеры предлагают целый набор услуг, из которых можно сконструировать инфраструктуру, подходящую именно для вашего проекта. В подобных случаях, как правило, от пользователя требуются глубокое понимание процесса развертывания и знание необходимых инструментов для удаленного обслуживания проекта. К таким провайдерам относятся Amazon Web Services (AWS) и Microsoft Azure. Отслеживать расходы на таких платформах гораздо сложнее, поскольку каждая услуга оплачивается отдельно.
• Многие пользователи разворачивают свои проекты на виртуальных частных серверах (virtual private server, VPS). При таком подходе вы арендуете виртуальный сервер, который действует как удаленный компьютер, авторизуетесь на нем, устанавливаете ПО, необходимое для работы вашего проекта, разворачиваете код, устанавливаете требуемые соединения и разрешаете серверу начать принимать запросы.
Регулярно появляются новые хостинговые платформы и способы взаимодействия с ними; подберите наиболее подходящие и потратьте время на изучение соответствующего процесса развертывания проектов. Длительное время поддерживайте свой проект, чтобы разобраться, какой аспект, опирающийся на подход вашего провайдера, эффективен, а какой — нет. Нет идеальных хостинг-провайдеров; вам придется постоянно оценивать, подходит ли выбранный провайдер под ваш проект.
Напоследок я хотел бы предостеречь вас от необдуманного выбора платформы хостинга и поиска некоего универсального подхода к развертыванию. Другие пользователи могут с энтузиазмом склонять вас к использованию сложных подходов к развертыванию и сервисов, которые призваны сделать ваш проект высоконадежным и способным обслуживать миллионы пользователей одномоментно. Многие программисты тратят много времени, денег и сил на выработку сложной стратегии развертывания, а потом обнаруживают, что их проектом почти никто не пользуется. Большинство проектов Django можно разместить на небольшом хостинге и настроить на обслуживание тысяч запросов в минуту. Если трафик вашего проекта укладывается в этот уровень, то потратьте время на конфигурацию развертывания для работы на минимальной платформе, прежде чем вкладывать деньги в инфраструктуру, предназначенную для крупнейших сайтов в мире.
Порой развертывание — невероятно сложная задача, но констатация факта, что ваш проект работает хорошо, вдохновляет. Наслаждайтесь решением этой сложной задачи и обращайтесь за помощью по мере необходимости.
