AWS Elastic Beanstalkを使ってDjangoアプリをデプロイしてみた(後編)
前回の記事では、クラウドサービスについて、おさらいしつつElastic Beanstalkを使ってみようと思ったきっかけについて、書いてみました。
後編では実際の手順も含めて、ハンズオン形式でご紹介します。
目次
- はじめに
- 実行環境
- ローカルで仮想環境をセットアップ
- Djangoのインストールとプロジェクト作成
- Elastic Beanstalkデプロイ前の準備
- Elastic Beanstalkにサイトをデプロイ
- 環境クリーニング
- まとめ
はじめに
アプリケーション作成のフレームワークは正直何でもよかったのですが、私自身アプリケーション開発経験があったのが、DjangoとRuby on Railsくらいなのと、RubyよりもPythonの方が使い慣れているということもあって、Djangoを選びました。
今回のテーマが「AWSのサービスを使ってみた」なので、詳しくは触れませんが、 実際に作ったアプリケーションなんかも、今後機会があればご紹介しようかと思います。
DjangoのアプリケーションをAWS Elastic Beanstalkにデプロイする流れは、AWSがドキュメントを公開しており、今回の検証も以下をベースに実施しました。
実行環境
今回、Elastic Beanstalkにデプロイする実行環境は以下です。
互換性によっては動作しないことがあるので、AWSとの動作保証が取れているバージョンを確認したうえで、実行してください。
ちなみに筆者が元々利用していたDjangoも3.1だったのでやり直しました(笑)
FAQ: Installation | Django documentation | Django
ローカルで仮想環境をセットアップ
Windows10で仮想環境をセットアップします。
コマンドプロンプトを立ち上げて、必要なパッケージをインストールします。
pip install virtualenv pip install awsebcli --upgrade --user
pythonやpipのインストールは本記事では取り上げないので、各自インストールしておいてください。
ちなみに、AWSのEB CLIはパスが通っていないと思いますので、以下の手順でパスを通すのもお忘れなく。
- Windows キーを押し「環境変数を編集」を検索してクリック
- ユーザの環境変数のPathを選択し、編集
- %USERPROFILE%\AppData\roaming\Python\Python38\scriptsを追加
- cmd再起動
その後、コマンドプロンプトを起動し、以下の通り、仮想環境を有効にしてください。 ここでは、eb-virtという名前で仮想環境を作成しました。
C:\>cd C:\Users\自身のユーザフォルダ //ホームパスへ移動 C:\Users\自身のユーザフォルダ>mkdir Django_workspace //Django_workspaceというプロジェクト用フォルダを作成 C:\Users\自身のユーザフォルダ>cd Django_workspace //Django_workspaceへ移動 C:\Users\自身のユーザフォルダ\Django_workspace>virtualenv .\eb-virt //仮想環境eb-virtを作成 C:\Users\自身のユーザフォルダ\Django_workspace>.\eb-virt\Scripts\activate //仮想環境を有効化 (eb-virt) C:\Users\自身のユーザ名\Django_workspace>
Djangoのインストールとプロジェクト作成
Djangoをインストールします。
(eb-virt)~$ pip install django==2.1.1 //先述の通り、執筆時点でDjango 2.2 は Elastic Beanstalk Python 3.6 プラットフォームと互換性がないため、2.1.1をインストールします。 (eb-virt)~$ pip freeze Django==2.1.1 ... //djangoのインストールを確認
Djangoのプロジェクトを作成します。
(eb-virt)~\Django_workspace$ django-admin startproject trial_django
Django_workspaceのtrial_djangoプロジェクトに移動し、Djangoサイトをローカルで実行します。
(eb-virt)~\Django_workspace$ cd .\trial_django (eb-virt)~\Django_workspace\trial_django$ python manage.py runserver
ブラウザで、http://127.0.0.1:8000/ へアクセスして動作確認します。
こんな感じの画面が出れば動作OKです!
Elastic Beanstalkデプロイ前の準備
pip freezeの実行結果を、requirements.txtに出力し保存します。 Elastic Beanstalk は requirements.txt を使用して、アプリケーションを実行する EC2 インスタンスにどのパッケージをインストールするかを判断するようです。
(eb-virt)~\Django_workspace$ pip freeze > requirements.txt
.ebextensionsという隠しフォルダをプロジェクトのディレクトリ配下に作成します。
(eb-virt)~\Django_workspace\trial_django$ mkdir .ebextensions //.ebextensions という名前のディレクトリを作成します。
C:\Users\自身のユーザフォルダ\trial_django.ebextensions\django.config
といったディレクトリ構造にて、django.configを作成し、以下の設定を追加します。
django.configへの設定内容は以下です。
option_settings: aws:elasticbeanstalk:container:python: WSGIPath: trial_django/wsgi.py
一旦、ここで仮想環境を無効化します。
(eb-virt)~$ deactivate
Elastic Beanstalkにサイトをデプロイ
eb initコマンドで、EB CLI リポジトリを初期化し、django-tutorialという名前のアプリケーションをAWS Elastic Beanstalk上に作成します。
~\Django_workspace$eb init -p python-3.6 django-tutorial //先述の通り、AWSではpython3.6をサポートしています。
初回実行時には、AWSに認証情報を求められますので、以下の通り認証情報を入力します。
(aws-access-id):AWSのAccess key ID (aws-secret-key):AWSのSecret access key
認証情報がわからない場合には、アマゾン ウェブ サービス全般のリファレンスの「セキュリティ認証情報の取得方法」を参照してください。
作成したアプリケーションが稼働するEC2インスタンスにSSHでアクセスできるようにするため、再度、eb initを実行し、キーペアを設定します。 既存のキーペアを使う場合は1)を、新たに作成する場合は2)を選択します。
2)を選択した場合は、設定後に実行したフォルダ上の隠しフォルダ.sshに公開鍵が保存されるので、アクセス時に利用できるよう、覚えておいてください。
~\Django_workspace$ eb init Do you want to set up SSH for your instances? (y/n): y Select a keypair. 1) my-keypair 2) [ Create new KeyPair ]
この時点では、django環境は作成していないのでプロジェクトのみですが、AWSのコンソール上からも作成が確認できます。
続いて、Djangoの環境を作成します。
~\Django_workspace$eb create django-test
作成後、eb status を実行して新しい環境のドメイン名を確認します。
~\Django_workspace$eb status Environment details for: django-test Application name: django-tutorial ... CNAME: それぞれのドメイン名が出力されます。 ...
続いて、 C:\Users\ng7mi\Django_workspace\trial_django\settings.py を編集し、eb statusで確認したドメインをALLOWED_HOSTS = ['']の''の間に追記します。 この時、ついでにTIME_ZONEをAsia/Tokyoに変更しておくといいです。
そしていよいよ!ローカルのDjangoアプリをElastic Beanstalkにデプロイします。
~\Django_workspace$eb deploy
以下のコマンドを実行すると設定したアプリケーションがAWSにデプロイされアクセスできることが確認できます。
~\Django_workspace$eb open
無事、ロケットの画面にアクセスできました。
コンソール画面でもヘルスチェックがOKになっていることがわかりますね。
加えて、EC2の画面を選択し、「実行中のインスタンス」や「ボリューム」、「ロードバランサ」を確認すると、アプリケーションの実行に必要なインフラが構成されていることが確認できます。
環境クリーニング
そして最後に、環境のクリーニングを紹介しておきます。
前編のブログ記事で述べた通り、このままだとインフラの利用分だけ課金されてしまうため、アプリケーションを公開する予定などない場合は、一旦環境を削除することをオススメします。
ローカルの環境でアプリが完成し次第、また、デプロイすればいいと思うので。
コマンドはシンプルです。
~/Django_workspace$ eb terminate django-test
確認のため、削除対象の環境の入力が再度求められますので、django-testと入力し、削除を完了させてください。
ただこのコマンドだけでは、同時に作成されるS3のバケットが残ってしまいます。
ということで、S3の手動削除もご紹介しておきます。
- GUIにログインして、S3のマネジメントコンソールへ。
対象のバケットを空にする。
- この状態では、バケットポリシーにより、削除ができません。
対象バケットの管理画面に入り、アクセス権限のタブを選択。
バケットポリシー選択し、削除を実行。
再度S3のマネジメントコンソールへ移動し、対象のバケットを削除。
まとめ
こんな感じで、簡単にアプリケーションをAWS上にデプロイすることができました!
もちろん、EC2で一からインフラを構築して、アプリケーションをデプロイするのもアリだとは思うのですが、Elastic Beanstalkを利用すると、格段にラクだと感じました。
デプロイの容易性だけでなく、オートスケールなど運用における利便性も、推奨できます。
前編の記事でも紹介しましたが、以下のハンズオンを実施すると、Elastic Beanstalkの手軽さを感じられるのと、出来上がっていく環境への理解も深まると思うので、時間があればご受講をお勧めします。
ちなみに無料です。
AWS Hands-on for Beginners | AWS
こんな感じで、簡単な検証記事もちょこちょこ上げられたらなと思いますので、気まぐれ更新ではありますが、お付き合いください。
先日から公開している、ダイエット体験記のようなものも上げつつ、セキュリティ以外のコンテンツにも挑戦しようかなと思うので、良かったらご覧ください。