kagoya の vps で django を動かしていますが、kagoya は 660 円/月とコスパが良く、また1日単位で課金されるのでいつでもやめることができます。
とても重宝していたのですが、先日ふと aws で django を動かせないかと思いました。
amazon prime に入ったので aws もいろいろとサービスが付いているのかと思ったのですが、amazon prime と aws は関係ないようです。
でも、aws で ubuntu をインストールして django を引っ越すことはできました。
aws はいくらかかるのか
私が現在使っているデータベースは django のダンプファイルとしても 1.4 MB 程度しかありません。
最近では画像も記録できるようにしてあるので、画像はやや重いのですが、それでも 70 MB ほどです。
最初はスマホで撮った写真をそのままアップしていましたが、それでは 1 枚当たり 2 MB にもなるので大きすぎ、最近では 300 KB 程度に圧縮するアプリをインストールして、圧縮した画像をデータベース化するようにしています。
なので、ubuntu のスペックとしては最小単位でいいので、以下のような無料利用枠で設定しました。
osイメージ : ubuntu 18.04
インスタンスタイプ : t2.micro
メモリ : 1 GB
ストレージ : 8 GB
よくわかっていないのですが、このスペックだと 1 年間はほとんど無料かと思っています。
aws はとてもわかりにくい
aws に ubuntu を設定して django を移動するのにほぼ半日を要しました。
いろいろ理由がありますが、基本的に aws の設定がとてもわかりにくいです。
ネット記事もいろいろと古い内容のものもあって、なかなか思うようにいかず、引っ越しはとても苦労しました。
インスタンスを作っては削除し、全部で 10 個ほど試したと思います。
最終的にはうまくいったのですが、現段階で理解していることを記録しておきます。
ssh のポート番号変更
どういうわけか aws からインスタンスに web 上で接続できないのですが、ローカルのコマンドラインからは ssh 接続できます。
いつもどおりに ssh のポート番号を変更します。
/etc/ssh/sshd_config
Port 11123
ssh 再起動。
sudo systemctl restart sshd
ubuntu のインスタンスを再起動。
aws のインスタンスのドメイン名は使えない
aws でインスタンスを作成すると、「ec2–11-22-33.ap-northeast-1.compute.amazonaws.com」というようなドメインが作成されます。
でもこのドメイン名は利用できません。
ムームードメインなどで新たにドメインを取得する必要があります。
この部分において最も有用だったネット記事は、仁科俊晴さんという人の記事でした。
この方のおかげで設定することができました。
ありがとうございました。
まずは、購入したドメイン名で「Route 53」でホストゾーンを作成すると以下のような情報を取得できます。
ns-219.awsdns-27.com.
ns-1896.awsdns-45.co.uk.
ns-1034.awsdns-01.org.
ns-688.awsdns-22.net.
この情報をムームドメイン側でも設定します。
django の引っ越しと設定
kagoya にあった django のアプリ全体を scp でローカルにダウンロードして、それを aws に scp でアップロードします。
私のブログですが、この記事を参考にして ubuntu にいろいろとインストールします。
することが多すぎて、最後にエラーが出るとその原因に辿り着くのは大変かもしれません。
なので途中で確認したいことがあります。
venv 環境でつながるかどうか確認します。
cd /home/django/testdjango/venv
source venv/bin/activate
sudo ufw allow 8000
gunicorn --bind 0.0.0.0:8000 config.wsgi
アドレスバーに「aws のIPアドレス」を書き込んで nignx 画面が出ればOKです。
/etc/nginx/sites-available/testdjango の設定
/etc/nginx/sites-available/testdjango でサーバー名を記載します。
/etc/nginx/sites-available/testdjango
server {
listen 80;
server_name VPSのIP;
location = /favicon.ico { access_log off; log_not_found off; }
location /static/ {
root /home/django/testdjango;
}
location / {
include proxy_params;
proxy_pass http://unix:/run/testdjango.sock;
}
}
もちろん「settings.py」の allowed host も変更します。
サイトの ssl 化
私がハマったのは自作のサイトの ssl 化でした。
どうしてもできません。
そうしてあれこれ調べているうちに、こんなサイトが。
「ACM(AWS Certificate Manager) は EC2 に設定できない」そうです。
ほとんどタダの aws に ssl まで発行しろというのは無理筋ですよね。
そこで、以前やったように自分で設定することにしました。
最初そうしたのですがどういうわけかうまくいきませんでした。
sudo apt-get update
sudo apt-get install software-properties-common
sudo add-apt-repository universe
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install certbot python-certbot-nginx
そうして自分のサイトを ssl 化します。
sudo certbot --nginx -d tamasan.site
と、こんなエラーメッセージが。
AttributeError: module 'lib' has no attribute 'X509_V_FLAG_CB_ISSUER_CHECK'
この解決法はネットにありました。
pip install pip --upgrade
pip install pyopenssl --upgrade
もう一度、やってみます。
途中でいろいろと聞かれますが、適当に。
kagoya を解約
kagoya の vps はコスパ抜群で、これまでいろいろ利用してきた vps の中では最高だと思っています。
でも、もう少しで年金生活になるため、スマホを格安にして車を国産の安い車種にして、ケーブルテレビを解約し、あれこれ削ってきました。
kagoya は1年間でせいぜい 8,000 円程度ですが、削れる部分は徹底的に削りたいと思っています。
実は aws でも課金されるかもしれないのですが、無駄なことはしたくないということと、私の趣味でもあるコンピュータで今回は面白い経験ができたと思っています。
ああ、そうそう。
新たにムームードメインで取得したドメインは 75 円でした。
1年間は使えますが、次の1年間の維持費は多分 5,000 円ほどになるんでしょうね。
そうなったら、また新しいドメインを取得すればいいだけですけどね。
AWS コスト管理
AWS コスト管理という画面を見ると、
やはりタダではなかったようです。
それにしても何に課金されたんだろう？
security group が削除できない
aws で django をやってみましたが、スペック的にとてもショボいことと課金の可能性があると考え、いっそのこと django で動かしていたアプリを laravel に変更して xserver で動かすことにしました。
そして、laravel が動くようになったので aws のインスタンスやら何やらをすべて削除しようと思ったのですが、security group が依存関係でなかなか削除できません。
私の場合は vpc 関係をすべて徹底的に破壊したら security group も全部削除できました。
aws は二度とやりません。
amazon から aws 課金メールが
amazon から aws の支払いメールが届きました。
やはり EC2 に課金されているようですね。
おかしいな、無料というタグをクリックして amazon のアカウントで入ったんですけどね。
あれこれやったので 700 円ちょっとの課金はしょうがないという気はしますが、しかし 11 月 1 日の課金はありえないと思います。
その時点では aws に触りもしていないので。
ちょっと納得いきません。
vpc が自然復活？
aws のコスト管理は「https://us-east-1.console.aws.amazon.com/cost-management/home#/dashboard」から閲覧できます。
当然ながら、インスタンスや vpc を削除した 11 月 29 日以降はコストは発生していません。
念の為、Route 53 ダッシュボードを見ると、
また復活しているように見えます。
削除しようとすると、以下のようなエラーメッセージが。
エラーが発生しました
ホストゾーンを削除するには、最初に Zone Apex の NS および SOA リソースレコードセット以外のすべてのリソースレコードセットを削除する必要があります。
最終的にはすべてを破壊しましたが、いくら何でも amozon、やり過ぎじゃないでしょうか？
どうしてこうなったのかわかりませんが、アメリカと東京の両方でインスタンスやら何やらを設定したのかもしれません。
今後も定期的にコスト管理をチェックする必要があります。
