Django 開発環境と運用環境との同期方法

LINEで送る
Pocket

Django 開発環境と運用環境との同期方法

開発環境は、Windows10、Django2.2、Pycharm、python3.7、PostgreSQLです。

運用環境はAWSのEC2クラウドコンピューティングです。

 

データベースを運用している場合、バックアップ、リストアをが必要になります。
本番運用環境へ移行後も機能追加などで、データベースのフィールド追加、変更、削除は必要になります。

また、検証のために本番運用データを検証用データベースに丸ごとコピーするなどの場合にもバックアップやリストアは必要な作業となります。

常に開発環境と本番運用環境の同期をとることが必要となります。

本記事では、パンク-タイヤというWebサイト構築して本番運用している場合の同期の取り方の一例を示します。

AWSへの変更手順

app_adは、仮のユーザ名です。ご自分のユーザ名に置き換えて下さい。
ip-172-31-99-999は、AWSの仮のipです。ご自分のipに置き換えて下さい。

1) ローカル側の最新版プログラムをGitへアップロードする。
2) ローカル側の最新版プログラムをローカルホルダーにバックアップする。
3) AWS側のデータベース「tire」をバックアップ

以下はflat-tireのAWS環境でのバックアップの例
flatc0131aws.backupは、バックアップ・ファイル名で任意の名前を付与する。

pg_dumpの場所確認

WinSCPのAWS側でのファイル検索で、
ファイルマスク:pg_dump.exe
検索結果:/home/app_ad/venv/bin

[app_ad@ip-172-31-99-999 ~]$ cd ~/venv
[app_ad@ip-172-31-99-999 venv]$ cd bin
[app_ad@ip-172-31-99-999 bin] $ pg_dump -Fc tire -f ~/venv/flat/dbback/flatc0131aws.backup
[app_ad@ip-172-31-99-999 bin]$

$ pg_dump -Fc tire -f ~/venv/flat/dbback/flatc0131aws.backup

オプションの詳細
-F 出力する際の形式を指定します(cがカスタム、tがtar、pがテキスト)
-f 出力するファイルを指定します。 ファイルを基にする出力形式ではこのパラメータは省くことができます。

4) AWS側のプログラムをバックアップ

flat以下のデータをWinSCPでローカル側にコピーして保存。

5) ローカル側で変更したデータベース名を「flat」とする。

ローカル側にて「flat」というデータベースを作成

DjangoのTerminalで新規「flat」データベースを作成
psql –version
psql -U postgres
postgres=# create database flat owner app_ad;

postgres=# \q

変更したデータベースをバックアップして、データベース・ファイル名を「flat20210211c.backup」とする。

ローカル側のflat開発環境でのデータベースバックアップの例

Django「flat」プロジェクトの「dbback」ホルダーにデータベース・ファイル「flat20210211c.backup」を格納する。

Windows Powershellを起動します。

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
新しいクロスプラットフォームの PowerShell をお試しください https://aka.ms/pscore6

PS C:\Users\user> psql –version
psql (PostgreSQL) 10.14
PS C:\Users\user> pg_dump -U app_ad -f ” C:\Users\user \PycharmProjects\flat\dbback\flat20210211c.backup” -Fc flat
パスワード:

オプションの詳細
-F 出力する際の形式を指定します(cがカスタム、tがtar、pがテキスト)
-f 出力するファイルを指定します。 ファイルを基にする出力形式ではこのパラメータは省くことができます。

 

6)Djangoの settings.pyで、データベース名を「flat」に変更
Pycharm側の
settings.pyで、データベース名を「flat」に変更するだけで切り替わる。

# データベース設定
DATABASES = {
‘default’: {
‘ENGINE’: ‘django.db.backends.postgresql_psycopg2’,

‘NAME’: ‘flat’,
# ‘USER’: os.environ.get(‘DB_USER’),
‘USER’: ‘app_ad’,  # ユーザ名
# ‘PASSWORD’: os.environ.get(‘DB_PASSWORD’),
‘PASSWORD’: ‘xxxxxxxx’,  # パスワード
‘HOST’: ”,
‘PORT’: ”,
}
}

7) Pycharm側(ローカル)の新規プログラムをWinSCPでAWS側(本番環境)に転送する。

AWSサーバー側の「flat」以下のディレクトリ&ファイルを右クリックで削除。
ローカル側のvenvディレクトリ以外をサーバー側に転送。

8) AWS側に新規に、「flat」というデータベースを作成
「tire」データベースは、変更前のデータベースとして温存しておき、何か支障が生じた場合にこのデータベースに切り替える。
「flat」データベースは変更後のデータベースとする。

$ sudo -u postgres -i psql

postgres=# create database flat owner app_ad;

postgres=# \q

9) ローカル側でリストアしたデータベース・ファイル「flat20210211c.backup」をAWS側の「flat」データベースにリストアする。

以下はflat-tireのAWS環境でのリストアの例

[app_ad@ip-172-31-99-999 ~]$ cd ~/venv
[app_ad@ip-172-31-99-999 venv]$ cd bin
[app_ad@ip-172-31-99-999 bin]$ pg_restore -Fc -c -d flat ~/venv/flat/dbback/flat20210211c.backup
[app_ad@ip-172-31-99-999 bin]$

$ pg_restore -Fc -c -d flat ~/venv/flat/dbback/flat20210211c.backup

オプションの詳細
-F アーカイブの形式を指定します。 pg_restoreは形式を自動認識するので、このオプションは必須ではありません。
(cがカスタム、tがtar、pがテキスト)
-c データベースを再作成前に、テーブルなどのデータベースオブジェクトを削除します
-d リストアするデータベースを指定します

10) nginxの再起動
  $ sudo systemctl restart nginx.service

  $ systemctl status nginx.service

11) Gunicornの再起動
  Python仮想環境に入る
  $ source ~/venv/bin/activate
  (venv) $ cd ~/venv/flat
  (venv) $ pkill gunicorn
  (venv) $ gunicorn –bind 127.0.0.1:8000 config.wsgi -D
  (venv) $ ps ax | grep gunicorn

パンク-タイヤサイトは、こちら

LINEで送る
Pocket