痛風とシステム障害を恐れるエンジニアのブログ

趣味のことだったり仕事に関することだったりを徒然なるままに。ｗｅｂとかオープン系の会社で働いてます。お仕事の依頼お待ちしておりまーす。

Djangoでつまづいた話。

Django Docker Nginx Python3 Pycharm

今試験的に作っているwebページはサーバーサイドをDjangoで作っているわけですが、今日は一般に公開しているサーバにデプロイした時に躓いたことをメモっておきますφ(..)
設定の話は細かすぎるから概論的なことを。

開発環境ではPycharmでデバッグをしているのですが、その時には何ら問題なかったソースがサーバに上げると途端に動かなくなりました。
Djangoはちゃんとリクエストを受け付けていて、viewの表示もしているけど、JSやCSS、その他の静的なコンテンツが全く表示されていませんでした。

ちなみに環境は

  • ホストOS。

　フロントのwebサーバー。リクエストを受け付けたらDjangoが動作するサーバーにリクエストを転送

  • Djangoが動作するDockerイメージ
  • PostgreSQLが動作するDockerイメージ（今回は無関係）

という感じでやってます。

結論からいうと、原因は私の設定漏れでした。
というのも、Djangoのそもそもの仕様を理解していなかったためです。

Djangoはセキュリティの観点から、静的なファイルはwebサーバに公開しているディレクトリに配置することを推奨してるみたいです。
プログラムファイルはまた別の仕組みで動いているみたい。
特段webに公開していません。

ですので本番で動かすときは行うこととして注意するのが

manage.py migrate
  • （必要があれば）静的なファイルのデプロイ
manage.py collectstatic

というコマンドを打つ必要があります。
ちなみにデプロイ時に静的なファイルを出力するフォルダの設定は
settings.pyで設定します。

STATIC_ROOT = "/var/www/html/static"

設定するフォルダはwebサーバから見れる場所じゃないといけません。

私の環境だとここで問題が。
もともとDjangoはDocker上で動いていて、Docker上のフォルダはwebサーバーからは一切見れない状況なのです。
Nginxの設定も任意のサブドメインにきたリクエストは全てDockerのDjangoにまるなげするような設定でした。
なので少し設定を変えました。
元のルール。

    location  /  {
        proxy_pass http://127.0.0.1:{dockerで開放しているポート};
    }

今回追加したルール

   location ^~/static/ {
       root /var/www/html/static;
   }

とし、上記で設定したフォルダはホストサーバとDockerとでの共有フォルダにしました。

まぁなんか変な感じだけど、動いたからいっか。

Djangoの設定に関しては、同じような悩みの方もおりました。
こちらでより詳しく解説されてます。stackoverflow.com

Djangoでつまづいた話。

今試験的に作っているwebページはサーバーサイドをDjangoで作っているわけですが、今日は一般に公開しているサーバにデプロイした時に躓いたことをメモっておきますφ(..)
設定の話は細かすぎるから概論的なことを。

開発環境ではPycharmでデバッグをしているのですが、その時には何ら問題なかったソースがサーバに上げると途端に動かなくなりました。
Djangoはちゃんとリクエストを受け付けていて、viewの表示もしているけど、JSやCSS、その他の静的なコンテンツが全く表示されていませんでした。

ちなみに環境は

  • ホストOS。

　フロントのwebサーバー。リクエストを受け付けたらDjangoが動作するサーバーにリクエストを転送

  • Djangoが動作するDockerイメージ
  • PostgreSQLが動作するDockerイメージ（今回は無関係）

という感じでやってます。

結論からいうと、原因は私の設定漏れでした。
というのも、Djangoのそもそもの仕様を理解していなかったためです。

Djangoはセキュリティの観点から、静的なファイルはwebサーバに公開しているディレクトリに配置することを推奨してるみたいです。
プログラムファイルはまた別の仕組みで動いているみたい。
特段webに公開していません。

ですので本番で動かすときは行うこととして注意するのが

manage.py migrate
  • （必要があれば）静的なファイルのデプロイ
manage.py collectstatic

というコマンドを打つ必要があります。
ちなみにデプロイ時に静的なファイルを出力するフォルダの設定は
settings.pyで設定します。

STATIC_ROOT = "/var/www/html/static"

設定するフォルダはwebサーバから見れる場所じゃないといけません。

私の環境だとここで問題が。
もともとDjangoはDocker上で動いていて、Docker上のフォルダはwebサーバーからは一切見れない状況なのです。
Nginxの設定も任意のサブドメインにきたリクエストは全てDockerのDjangoにまるなげするような設定でした。
なので少し設定を変えました。
元のルール。

    location  /  {
        proxy_pass http://127.0.0.1:{dockerで開放しているポート};
    }

今回追加したルール

   location ^~/static/ {
       root /var/www/html/static;
   }

とし、上記で設定したフォルダはホストサーバとDockerとでの共有フォルダにしました。

まぁなんか変な感じだけど、動いたからいっか。

Djangoの設定に関しては、同じような悩みの方もおりました。
こちらでより詳しく解説されてます。stackoverflow.com

React.jsをさわりはじめてみた記念日

React.js React.j

React.jsはFacebook謹製のJSライブラリで半年ほど前にも触ったことがあったのですが、その時は日本語のチュートリアルがなかったのと、後述しますがJSXからのコンパイル環境を整えられなくて、私には使いこなせてないなぁという感じが強かったので遠のいてました。
ところが、ここ最近日本語の公式チュートリアルができていたので、また再チャレンジをしてみた次第。

とりあえず、今作っているサイトのフロント部分で使えるようになりたい・・・。
頑張ろ。

まずは公式の日本語チュートリアル。facebook.github.io

気のせいだろうか・・・本家のと内容が若干違うような？？
まぁいいや。

React.jsの特徴としてJSXという記法で記述できるというのがあるらしいです。
XMLのような形で記述できるので書きやすいんだとか。
（そう思える余裕が今の自分にはないｗ）

流れとしては
JSXで書く→JSにコンパイル→フロントで呼びされる。
という感じで、コンパイルをオンラインでやることもできるけど、その分余分な処理が発生するので本番では使えない。
本番ではJSにコンパイルしたのを用意しておく形になるみたい。

JSXの書き方は

var CommentBox = React.createClass({
  render: function() {
    return (
      <div className="commentBox">
        Hello, world! I am a CommentBox.
      </div>
    );
  }
});
ReactDOM.render(
  <CommentBox />,
  document.getElementById('content')
);

タグの中にclassNameというのがあるのがまた特徴的ですな。
classは諸事情により使えないらしい。

jsxファイルをJSファイルにコンパイルする環境がチュートリアルにものってますが、npmありきでかいてるのでnpmから。
npmのインストール

brew install node

Reactの何かのツールのインストール

npm install -g react-tools

環境が整ったところでjsxをコンパイルしてみる。

jsx --watch src/ build/

このコマンドをすると

すると、src/helloword.js に変更を加えるごとに build/helloworld.js が自動で生成されるようになります。

とマニュアルにはあるけど、結局生成されなかった・・・。
最終的に生成できたコマンドは

jsx -x jsx src/ build/

これだと常に監視はせず、都度都度必要に応じて実行する必要があるけど、文法エラーとかもコンパイル時に出てくれるので便利。
マニュアルのはなぜ動かないのか謎だけど、とりあえず、当面はこのスタイルで触っていこうかなーと思ってるところです。

AnsibleでWordpressの環境を構築してみたンゴ その2

Ansible

playbookを作っていると、だらだらと冗長的な作りになってしまって、記述量が多くなると、どこに何を書いてるのかわかりづらくなってきました。
そこで何か良い方法がないものかと調べてみました。

続きを読む

AnsibleでWordpressの環境を構築してみたンゴ その1

Ansible Wordpress Vagrant

前回のAnsibleの環境構築はなんやかんやいろいろやったら動くようになりました。

  • pipをPython2系でインストールし、pip経由でAnsibleをインストールする
  • playbookの記述を見直す←記述ミスがあったので、これがちゃんと動かなかった原因かも？

pythonの文化を引き継いでいるのでインデントの設定が間違っていたりすると途端に動かなくるっぽい？

Ansibleが動くようになったので（Vagrant上の）CentOS7にPHPとMySQLとNginxとWordpressをインストールしてみました。

続きを読む

Ansibleを入れてみた

Ansible

なんとなくAnsibleを入れてみました。
同じような環境を作るときとか便利そうなので。
Maxにインストールしてみます。

brew install ansible
#インストールされたバージョンの確認
ansible --version
ansible 1.9.2

最初はこれでネットの文献を見ながらいろいろやってみたけど、どうもplaybookの読み込みなどがうまくいかない・・・。
とりあえず、公式サイトを覗いてみると、MacへのAnsibleのインストールはpip経由になってるので、もしかして古いのが入ったのかなーと思い入れなおしてみました。

brew uninstall ansible
pip intall ansible
||>

として動かしてみたけど、それでも動かない。。

どうもAnsibleってPython2系で動かすみたいですね。
3系はまだ対応してない疑惑が。。。

Djangoの設定ファイルの読み込みを実行環境ごとに分けてみる

Django Pycharm Python3

ローカルの開発環境と本番の実行環境とでDjangoを動かすときに、データベースの設定やDEBUGフラグの設定など、都度都度切り替えるのもめんどくさいので、なにかよい方法がないかと色々と試してみたのでその過程をメモっておきます。

続きを読む