pgAdmin 4 | Развёртывание сервера

pgAdmin можно переделать в веб-приложение, зашифровав приложение для запуска в режиме сервера, а затем развернув его либо за веб-сервером, работающим как обратный прокси, либо с использованием интерфейса WSGI.

При повторном запуске в режиме сервера пользователи имеют два заметных отличия:

Пользователи должны войти в систему, прежде чем они смогут использовать pgAdmin. Начальный аккаунт суперпользователя создаётся при запуске режима сервера, и этот пользователь может добавлять дополнительных суперпользователей и не суперпользователей по мере необходимости.
Хранилище файлов предоставляется в виртуальном корневом каталоге для каждого отдельного пользователя в соответствии с конфигурацией каталога с использованием параметра конфигурации STORAGE_DIR. Пользователи не имеют доступа ко всей файловой системе сервера.

Следующие инструкции демонстрируют, как pgAdmin может быть запущен как приложение WSGI под Apache HTTPD, с использованием mod_wsgi, автономно с использованием uWSGI или Gunicorn или под NGINX с использованием uWSGI или Gunicorn.

Смотрите также

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

Требования

Важно: Некоторые компоненты pgAdmin требуют возможности поддерживать связь между сеансами клиента и определённым подключением к базе данных (например, средство запроса, в котором пользователь может выполнить команду BEGIN, за которой следует ряд инструкций DML SQL, а затем COMMIT). pgAdmin был разработан со встроенным управлением подключениями для решения этой проблемы, однако для этого требуется, чтобы использовался только один процесс Python, поскольку нелегко поддерживать связь между клиентским сеансом и одним из нескольких рабочих процессов WSGI.

В системах Windows HTTP-сервер Apache использует одно-процессную много-поточную архитектуру. Приложения WSGI работают во встроенном режиме embedded, что означает, что на этой платформе во всех случаях будет присутствовать только один процесс.

В системах Unix HTTP-сервер Apache обычно использует много-процессную одно-поточную архитектуру (это зависит от MPM, выбранного во время компиляции). Если для приложения WSGI выбран встроенный режим embedded, то для каждого процесса Apache будет одна среда Python, каждая со своим собственным менеджером подключений, что приведёт к потере привязки к соединению. Поэтому следует использовать режим daemon демона mod_wsgi, настроенный на использование одного процесса. Это приведет к запуску единственного экземпляра приложения WSGI, которое используется всеми рабочими процессами Apache.

Хотя это правда, что это потенциальное узкое место в производительности, на самом деле pgAdmin — это не веб-приложение, которое когда-либо будет видеть интенсивный трафик, в отличие от загруженного веб-сайта, поэтому на практике это не должно быть проблемой.

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

Конфигурация

Чтобы настроить pgAdmin для работы в режиме сервера, может потребоваться настроить код Python для работы в многопользовательском режиме, а затем настроить веб-сервер для поиска и выполнения кода.

Смотрите Файл config.py для получения дополнительной информации о параметрах конфигурации.

Конфигурация Python

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

Чтобы настроить код Python, выполните следующие действия:

1. Создать config_local.py файл рядом с существующим config.py файл.

2. Редактировать config_local.py и добавьте следующие настройки. В большинстве случаев расположение файлов по умолчанию должно быть соответствующим:

Примечание: Вы должны убедиться, что указанные каталоги доступны для записи пользователем, что процессы веб-сервера будут выполняться как, например, apache или www-data.

LOG_FILE = ‘/var/log/pgadmin4/pgadmin4.log’

SQLITE_PATH = ‘/var/lib/pgadmin4/pgadmin4.db’

SESSION_DB_PATH = ‘/var/lib/pgadmin4/sessions’

STORAGE_DIR = ‘/var/lib/pgadmin4/storage’

3. Выполните следующую команду для создания базы данных конфигурации:

# python setup.py

4. Измените владельца базы данных конфигурации на пользователя, от имени которого будут выполняться процессы веб-сервера, например, предполагая, что веб-сервер работает как пользователь www-data в группе www-data и что путь SQLite — /var/lib/pgadmin4/pgadmin4.db:

# chown www-data:www-data /var/lib/pgadmin4/pgadmin4.db

Хостинг

Существует множество возможных способов размещения pgAdmin в режиме сервера. Ниже приведены некоторые примеры:

Конфигурация Apache HTTPD (Windows)

После настройки Apache HTTP для поддержки mod_wsgi приложение pgAdmin можно настроить аналогично приведённому ниже примеру:

<VirtualHost *>
  ServerName pgadmin.example.com
  WSGIScriptAlias / "C:\Program Files\pgAdmin4\web\pgAdmin4.wsgi"
  <Directory "C:\Program Files\pgAdmin4\web">
    Order deny,allow
    Allow from all
  </Directory>
</VirtualHost>

Теперь откройте файл C:\Program Files\pgAdmin4\web\pgAdmin4.wsgi в своём любимом редакторе и добавьте приведённый ниже код, который активирует виртуальную среду Python при запуске сервера Apache.

activate_this = 'C:\Program Files\pgAdmin4\venv\Scripts\activate_this.py'
exec(open(activate_this).read())

Примечание: Изменения, внесенные в файл pgAdmin4.wsgi, будут восстановлены при обновлении или понижении версии pgAdmin4.

Конфигурация Apache HTTPD (Linux/Unix)

После настройки Apache HTTP для поддержки mod_wsgi приложение pgAdmin можно настроить аналогично приведенному ниже примеру:

<VirtualHost *>
   ServerName pgadmin.example.com

   WSGIDaemonProcess pgadmin processes=1 threads=25 python-home=/path/to/python/virtualenv
   WSGIScriptAlias / /opt/pgAdmin4/web/pgAdmin4.wsgi

   <Directory /opt/pgAdmin4/web>
      WSGIProcessGroup pgadmin
      WSGIApplicationGroup %{GLOBAL}
      Order deny,allow
      Allow from all
   </Directory>
</VirtualHost>

Примечание: Если вы используете Apache HTTPD 2.4 или более позднюю версию, замените строки:

Order deny,allow
Allow from all

с участием:

Require all granted

Настройте по мере необходимости в соответствии с вашими требованиями к контролю доступа.

Автономная конфигурация Gunicorn

pgAdmin может размещаться на Gunicorn напрямую, просто выполнив команду, подобную показанной ниже. Обратите внимание, что в этом примере предполагается, что pgAdmin был установлен с помощью Колеса Python (вам может потребоваться изменить путь в соответствии с вашей установкой):

gunicorn --bind 0.0.0.0:80 \
   --workers=1 \
   --threads=25 \
   --chdir /usr/lib/python3.7/dist-packages/pgadmin4 \
   pgAdmin4:app

Автономная конфигурация uWSGI

pgAdmin может размещаться на uWSGI напрямую, просто выполнив команду, подобную показанной ниже. Обратите внимание, что в этом примере предполагается, что pgAdmin был установлен с помощью Колеса Python (вам может потребоваться изменить путь в соответствии с вашей установкой):

uwsgi --http-socket 0.0.0.0:80 \
   --processes 1 \
   --threads 25 \
   --chdir /usr/lib/python3.7/dist-packages/pgadmin4/ \
   --mount /=pgAdmin4:app

Конфигурация NGINX с Gunicorn

pgAdmin может размещаться на Gunicorn с NGINX перед ним. Обратите внимание, что в этих примерах предполагается, что pgAdmin был установлен с помощью Колеса Python (вам может потребоваться изменить путь в соответствии с вашей установкой).

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

gunicorn --bind unix:/tmp/pgadmin4.sock \
   --workers=1 \
   --threads=25 \
   --chdir /usr/lib/python3.7/dist-packages/pgadmin4 \
   pgAdmin4:app

И настройте NGINX:

location / {
   include proxy_params;
   proxy_pass http://unix:/tmp/pgadmin4.sock;
}

Кроме того, pgAdmin можно разместить в подкаталоге (в данном случае /pgadmin4) на сервере. Запустите Gunicorn, как при использовании корневого каталога, но настройте NGINX следующим образом:

location /pgadmin4/ {
   include proxy_params;
   proxy_pass http://unix:/tmp/pgadmin4.sock;
   proxy_set_header X-Script-Name /pgadmin4;
}

Конфигурация NGINX с uWSGI

pgAdmin может размещаться на uWSGI с NGINX перед ним. Обратите внимание, что в этих примерах предполагается, что pgAdmin был установлен с помощью Колеса Python (вам может потребоваться изменить путь в соответствии с вашей установкой).

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

uwsgi --socket /tmp/pgadmin4.sock \
   --processes 1 \
   --threads 25 \
   --chdir /usr/lib/python3.7/dist-packages/pgadmin4/ \
   --manage-script-name \
   --mount /=pgAdmin4:app

И настройте NGINX:

location / { try_files $uri @pgadmin4; }
location @pgadmin4 {
    include uwsgi_params;
    uwsgi_pass unix:/tmp/pgadmin4.sock;
}

Кроме того, pgAdmin можно разместить в подкаталоге (в данном случае /pgadmin4) на сервере. Запустите uWSGI, обратив внимание на то, что в параметре mount указано имя каталога:

uwsgi --socket /tmp/pgadmin4.sock \
      --processes 1 \
      --threads 25 \
      --chdir /usr/lib/python3.7/dist-packages/pgadmin4/ \
      --manage-script-name \
      --mount /pgadmin4=pgAdmin4:app

Затем настройте NGINX:

location = /pgadmin4 { rewrite ^ /pgadmin4/; }
location /pgadmin4 { try_files $uri @pgadmin4; }
location @pgadmin4 {
  include uwsgi_params;
  uwsgi_pass unix:/tmp/pgadmin4.sock;
}

Информационные ссылки

Стандарт pgAdmin — https://www.pgadmin.org/docs/pgadmin4/6.9/server_deployment.html