8
14

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

【まとめ】GCP無料枠で非エンジニアがアプリ(django+uwsgi+nginx+supervisor)をデプロイするまで

Last updated at Posted at 2019-05-02

はじめに

さっきできました!
ついに…!ついに…!自分のドメインでWebページが見れるように!
(サイトを作ったとは言ってない)

誰かが鉄は熱いうちに打てといっていたので、覚えているうちに
今回は以下の2点を目的としてまとめ記事を書こうと思います。

  • 自身の振り返りとして
  • 同じことをやろうとする人向けのまとめ記事として

この記事でわかること

2019/05/02時点でのGCPを介したdjangoアプリのデプロイ過程がわかります。
今回は下記を利用して、まずは独自ドメインでdjangoTOPページを見れるようにしました。

  • django
  • uwsgi
  • nginx
  • supervisor

なんせこれらでデプロイしようとすると、参考記事がいろんなところに…
しかも古かったり…(きれそう)

というわけで、現時点(2019/05/02)での筆者が参照した記事やブログなりをまとめつつ
起きた問題を追記しました。
せっかくなら、皆さんの役に立てればと思い記事に。

基本的に参考にしたブログや記事を載せつつ、困ったところを書きます。
各ステップでは記事を参考にしてください。

筆者スペック

24歳 某事業会社にてマーケティング職
経験値としては、rails tutorialやったことあるくらい(完走はせず)
インフラとかわからなすぎて笑った

手順

GCPの設定いろいろ

まずはGCPのアカウント取得から。
基本的な環境設定をここで進めていきます。

以下の記事が神でした。
GCPで永久無料枠を利用してサービスを立ち上げたときにしたことの備忘録

ただし、railsでの対応を書いています。
nginxの設定ファイルやサーバーが自動で起動するようにするあたりは無視しましょう。
nginxの設定まで進んだら、次のステップに進んで下さい。

GCPでのSSH接続がわからねえって方はこちら
GCPでサーバーを立て、SSH接続するまで

問題①sshd_config編集後にssh接続ができない…

sshを22から指定した番号へ切り替えると同時に22番を閉じました。
するとsshコマンドで、ポート切り替え後にログインできないのです…

解決策

sshd_configでポート番号を変更しているため、もとの22番はNG
コマンドを下記のように変更。

# 変更前
$ ssh worker@<IPアドレス> -i ~/.ssh/my-ssh-key

# 変更後(ポート番号を指定すればええんや!)
$ ssh -p <ポート番号> worker@<IPアドレス> -i ~/.ssh/my-ssh-key

GCEにdjangoいれる

この記事にお世話になりすぎました。
GCE + Nginx + uWSGI + Django + Supervisor を使ってDjangoアプリをデプロイ

序盤のGCP関連は、前節で対応できるはず。
ただし、以後はdjangoを利用したいため、下記のインストールあたりから参考にしてください。

$ sudo apt-get install python3-pip nginx
$ pip3 install django==2.0.2 uwsgi
$ sudo apt-get install uwsgi uwsgi-plugin-python3
$ sudo apt-get install supervisor

問題②git cloneができない…?

今回はアプリケーションはどうでもよくって、とにかく見れるようになることが主眼です。
そのため、適当なdjangoアプリをgit cloneで持ってこようという算段。

「さらっとgit cloneして完了〜♪」のはずが、、全然できなかったです…

Permission denied (publickey).

sshkeyまわりだとはわかりつつ、新たに追加するも失敗。
今回の対応としては、GCPが提供するプライベートGitレポジトリサービス
「Cloud Source Repositories」を利用することで回避。

以下を参考にしました。
GCP Cloud Source Repositoriesを利用する手順のメモ

本来であれば、ローカルでの編集のように
githubなりgitlabなりにSSH接続してpushできる方が個人的には楽です。
問題なくできるなら、通常通りsshをしましょう。

いざ!NGINX!

無事にdjangoプロジェクトをcloneできたら、nginx-uwsgi-djangoのつなぎ込みです。
先程の記事を参考に進めましょう。

困ったときは、下記も同じようなことを書いているので参照しました。
Django + uWSGI + nginx (uWSGIチュートリアルの和訳)

基本的に記載のとおりで実施できました。
ただし、僕は後ほどエラーをだしてすごい悩んだので、
Django + uWSGI + nginx がどういった構造でクライアントからのリクエストに対応しているかは
なんとなくで理解した方がいいです。

confファイルをかなりいじりますが、僕はconfの参照がうまくできずに
ずっとnginxの画面をみてました…

/etc/nginx/nginx.conf
http {
 ~  ~
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;   # <----- この記述がありますか?
 # 例
 server {
  hogehoge
 }
}

ドメイン取得してGDSで設定

現時点では、nginxとuwsgiを使って固定IPでならdjangoのTOPページが見れています。
ここからは、独自ドメインでの設定とhttps化です。

僕はお名前ドットコムでドメインを取得し、下記の記事を参考にしました。
Google Cloud DNSでIPアドレスとドメイン名を紐付ける

SSL対応

残るはhttps化です。
最初にお世話になった記事へ帰ってきて、nginxを停止させて対応を進めましょう。
GCPで永久無料枠を利用してサービスを立ち上げたときにしたことの備忘録

ちなみに、僕はsupervisorを使ってデーモン化していたため、
nginxの停止一つでえらく時間を消費しました。

ポート番号の利用について調査するならlsofコマンドがおすすめです。
下記のコマンドでインストールした上で、調査してください。
過去にもあったんですけど、ずっと8000番を何者かが利用してくるんですよね…
(前は5年前に動かしたapacheが犯人だった)

# debian ならこれでインストール
sudo apt-get install lsof

# ポートの利用を調べるならこれ
lsof -i:<ポート番号>

そのうえで、supervisorを一度停止させましょう
こんな感じになればOK

user@pjname$ sudo supervisorctl
<プロジェクト名とか>                    STOP   pid 28621, uptime 1:51:3

あとは記事通りに作業を進めていくだけ。
唯一、リダイレクト処理を書く際には、defaultファイルではなく
作成した_nginx.confに書くようにしましょう。

僕は新たに作成したdefaultファイルのおかげで、深い闇に落ちました。

/etc/nginx/sites-enabled/hoge_nginx.conf
  server_name ドメイン;
    return 301 https://$host$request_uri; #受け取ったpathやhostを引き継いだ状態でhttpsでリダイレクトする

いかがでしょう。
このような問題が起きなければ、無事にSSL対応ができたのではないでしょうか。
最後にsupervisorを起こすか、コマンドで直接uwsgiとnginxを使って表示させてみましょう。
独自ドメインでのアクセスができるはず…!

同じように初心者ながらもdjangoでなんかやりたい人の手助けになれば幸いです。

教訓

やっぱり以下の内容は大事でした。

  • エラーは逃げずに読む
  • コマンドを打つ前に、自身の想定した挙動と現状のギャップを理解する

エラーは逃げずに読む

結局のところ、何が起きてるかはエラーにしか存在しません。
たまに疲れてきて、同じようなコマンドを打つこともありますが、有効だった試しはないです。

会社の上司と違って、何がだめだったかを明確に伝えてくれるできるやつなので
エラーはちゃんと読みましょう。

コマンドを打つ前に、自身の想定した挙動と現状のギャップを理解する

上の話にも通じますが、色々と調べたり、コマンドを打つ前にすることってあるなと感じました。

「なんで?」って思考が先行しますが、
まずは想定したプロセスのうちどこで事故を起こしたのかを理解することが解決につながります。
コマンド打ちまくって反省しました…

言い得て妙だと感じたのは、@jnchitoさんの記事ですね。
デバッグは「うまく動かないピタゴラ装置の原因調査」だと考えてみよう

謝辞

ここまでくるのにqiita記事やブログを大変参考にさせていただきました。
皆さんがその過程を公開してくれたおかげで、
僕は無事に自分のWebサイトを作る第1歩を踏み出せています。

本当にありがとうございましたm(_ _)m

参考記事一覧

8
14
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
14

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?