「nginx」の記事 - Crieit

【障害切り分けのコツはまずは森を見ること！】Gitlabのpushエラー、原因は（恐らく？）buffalo製ルータだった話

2022-02-24T23:29:56+09:00

お久しぶりですにゃ。
やらなきゃいけない事があるからと、”優先度の低いものをする時間をマストタスクに割り当てよう”と考えながら
、結局マスト作業も先延ばしになり帳尻合わせが大変になる時空を生きて21年目の私です😢

実はこの間に、所属している会社のブログも1ページながら担当させていただきましたねこ！業務内容とおすすめ焼酎４選という内容なので、
良かったら探してみて欲しいぎょぴ！！
（さすがにネコ語は自重しましたぎょぴぼー）
貴重な経験をさせてくださった弊社の担当者様、ありがとうございますにゃー！

久しぶりの投稿ということで前置きが長くなってしまいましたが、
今回は自宅で特定の通信がハングアップしてしまったときのことを綴りますぴょん。
※解決法とういうよりは、ハチャメチャに慌ててる私をご覧いただく記事となります。

v目次にゃv

1.今回起こった問題
2.一旦バックグラウンド
3.対処１
4.対処２
5. 切り分け
6. 今回の件から私が得るべき教訓は…
7. エンドタイトル

今回起こった問題

自宅クライアントPCからドメインでGitlabへ200MB付近の容量ファイルをgit pushすると

error: RPC failed; curl 56 Recv failure: Connection was reset
fatal: The remote end hung up unexpectedly

とのエラーが出てpushできない。※今回は19MBのサイズでエラー出ました
どうやらサイズ制限にかかり、正常にpushできていないみたい。
※ファイルサイズが小さいものは問題なくpushできます。

〇　5KB
✖　19MB

一旦バックグラウンド

唐突ですが、当時の自宅の簡単な構成を…

Windowsサーバより外の構成は私関与していなかったので、聞き伝えでの図ですが…
今回、外部からWebサーバにアクセスできるようにbuffaloルータでポート開放されていますうさぎ～。

また、CentOS内部では、80番ポートはプロジェクト管理ソフトWebGUIへ（Apache）
GitLabはパッケージ内包のNginxで動いています。
hoge/projectsとhoge/gitlabでサブディレクトリにして、Apaceでリバースプロキシ設定で運用していますきんぎょ～。
今回アクセスする経路はドメイン指定するので1度インターネット抜けしてからLAN内にあるサーバに戻ってくる形です。（混乱する要因の1つ）
この辺の詳細は省きます。わけわかランボルギーニ～(^^♪＜ふんっ！ふんっ！

対処１

原因を調べたところ、GItLab側（Nginx）で一定値を超えるものは制限をかけているらしい。（そもそも大容量通信を想定していない）
早速、ネットに記載されていた対処法を試すねこ！

まずはクライアント側でバッファを増やす設定をするにゃ

git config --global http.postBuffer 524288000

次にサーバ側のＧitlabのサイズ制限を変更するために、Nginxのconfigに追記するぎょぴぼー。

client_max_body_size 200M

その後、各ソフトとサーバーを再起動っぽ！
。
。
。
同じエラーが返ってくる…

対処２

根気強くネットで解決策をさがすと、”プロキシを挟まずに直でGitlabにつないだらいけた！！”との記事を発見！
バックグラウンドを見ていただくと分かると思いますが、自宅構成では
クライアントからGitlabに行く際に、リバースプロキシを介しています。
しかし、リバースプロキシを使わないと、Gitlabかプロジェクト管理GUIのどちらか一方しかアクセス出来なくなりますぴょん…
もちろん、URLでポート指定すればよいのですが、ユーザ側の負担が増えるため却下ですにゃ…
というか、そもそもApacheにデフォルトでサイズ制限はないらしい！！（もしかしたらという事もあるので一応設定をいろいろ試しました）

切り分け

ここまで、サーバ側、もしくはクライアントの設定を疑い試行錯誤してきましたが、一向に解決しないため、
サーバ内だけでなく全体を見て切り分けを行いましたきんぎょ。
通常なら切り分けを最初にするべきですが、ネット上に同じ問題に直面している方がおり、
さらに解決策まで載っているという事で先入観を持ってしまったのが私の敗因ですねこ…

まずはリバースプロキシが原因かどうかを確認するため、
新しくテスト仮想サーバをつくり、Gitlabだけ構築します。
Gitlabは設定を変更せず、リポジトリだけ作成し、大容量push時にエラーを返す状態を再現します。
ドメインを紐づけるのはめんどくさかったので、プライベートIPで開くようにしました。

↓リポジトリパス↓

http:\192.168.100.101/gitlab/piyopiyo.git

###push 結果↓
〇　5KBのデータ　　←小さいファイルはOKですね
〇　19MBのデータ　←え！？pushできた！！！！

ということは、GitlabやNginxは問題なし。リバースプロキシが怪しい…
前段階でリバースプロキシは違うと踏んでただけに驚きました。

より本番環境に近い（外部からのアクセス）挙動も確認したいので、一応ドメインとIPを紐づける（もちろん本番環境のIPは重複を避け変更しておく）
クライアント側でリポジトリのパスをドメイン指定に変更
↓リポジトリパス↓

http:\hogehoge.nk/gitlab.piyopiyo.git

###push 結果↓
〇　5KBのデータ　　←小さいファイルはOK
✖　19MBのデータ　 ←あれ、いつものエラーで通らない…💦

小さいファイルは通っているのでDNSの根本的な間違えはなさそう…
今回はリバースプロキシは設定していないので、リバースプロキシのせいでエラーが出るわけではなさそう
もしや、wanを抜ける過程で失敗している？？

テスト仮想サーバを閉じ、本番サーバのIPとドメインを紐づけ直して再度検証

###push 結果↓
〇　5KBのデータ　　←小さいのは通った！
✖　19MBのデータ　 ←通らない

この場合、以下の2つ範囲で考えることが出来ますね。
①プロバイダ側で何かしら制限がある（これだったらお手上げです😢）
②自分の管轄範囲のNWで問題がある

~~想定できる原因~~
・大容量通信は弾いている
　→Youtube等の大容量のデータはup,down共に正常に疎通可能。おそらく違う。

・特定プロトコルの大容量データを弾いている
　→gitの仕様詳細まで分からず、未検証。（今回はサイズによらずHTTPを使っているはず）

・十分な帯域が確保できず、通信量を絞っている
　→サーバ側のタイムアウト時間も延長したがダメ

Lanでは繋がり、Wanでは繋がらない（小さいデータは繋がるが）という事で、私の手が届く1番Wan側のbuffaloルータを詳しく見てみます。
設定を覗いた感じ、QoSが設定してあるわけでもなく、問題はなさそう。
機器固有の設定は不明なので、我が家にあるFortiGateに置き換えることにしたにゃ！

ついでなので、セグメント別けしました。（NW図の構成が甘くてすみません）

FortiGateの設定を行い、接続確認をしました。
↓リポジトリパス↓

http:\hogehoge.nk/gitlab.piyopiyo.git

###push 結果↓
〇　5KBのデータ　　←小さいファイルはOK
〇　19MBのデータ　 ←無事に通った！

通常利用が想定されるWanを介しての大小データのpushに成功したのにゃ！！

今回の件から私が得るべき教訓は…

まずは、今回、問題解決に至るまでのネックポイント
・ネット記事に、同一サーバにWebサーバを同時導入（リバースプロキシ使用）例が少ない
・GitHubの方がユーザが多くGitlabはどちらかといえば少数派なため、なぜかGithubの記事に案内される
・Hyper-vよりDockerを使用している例が多いため、解決法がマッチしない
・buffaloルータの仕様を理解できていない

以上を踏まえ、今回の件から私が得るべき教訓は、全体を見て切り分けをしっかりしよう！ということだ。

↓今回の切り分け例↓
サーバサイド
・リバースプロキシがおかしい
・Gitlabがおかしい
・Nginxがおかしい
・ポートやファイアウォールの設定がうまく機能していない
その他物理
・クライアントの設定ミス
・物理機器の故障、謎仕様
ネットワークサイド
・Wan側がおかしい
・Lan側がおかしい
・NW境界部がうまく機能していない

てっきりサーバ側だと思い込んでそちらばかり対応にあたったのがダメでした。
今回はネットワークサイド、NW境界部（buffaloルータの仕様なのかな？）があたりでしたね…
結局、最たる原因は仕様が不明のため、buffaloさんには問い合わせて回答をいただく予定です。

エンドタイトル

今回は個人的にいろいろな事象が複雑に面倒くさく絡まっていたのが、解決への道を妨げるものでした。
リソースの関係上仕方がないとはいえ、シンプルな設計の重要さを身をもって学びました。み〇ほ銀行のジャングルシステムがいい例ですね。いや、悪い例か…
複雑なものをどのようにまとめようか思考しながら筆をとった結果、語尾も中途半端になる始末…（しかも非常に読みづらくて申し訳ない）

今回はここまで🐾
自宅にて、焼酎のお湯割りを飲みながら…。

次回も頑張るきんぎょー…

編集後記

私のCrieit記事では、私個人の思ったことや考えを色濃く記事に出しています。qiitaやStack Overflowのような解決を求める記事や、参考となる記事とは違い、実際に困難（？）に直面しているへっぽこ技術者の狭い視野やドキドキを臨場感のある雰囲気を含め楽しんで屍を越えて下されば幸いです。

せっかくなので、次回あたりFortiGateの設定などもご紹介できればよいですにゃ～…

nginx + uWSGI + Flask で python webアプリを立ち上げる

2021-01-13T15:45:49+09:00

nginx + uWSGI + Flask で python webアプリを立ち上げる

開発中は Flask の dev server で良いのだけれど、リリース時にはフロントのHTTPサーバを用意する必要がある。

Deployment は選択肢がいくつかあるけれど、今回はUbuntu上で、HTTPサーバに nginx、Flaskで作ったPython Webアプリを動かす WSGIコンテナに uWSGI を使った構成の設定例。

インストール

nginx, uwsgi, Flask をインストールする。uwsgi と Flask は venv 環境で。

$ uname -a
Linux hoge-machine 5.4.0-52-generic #57~18.04.1-Ubuntu SMP Thu Oct 15 14:04:49 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ sudo apt install nginx
$ python3 -V
Python 3.6.9
$ mkdir venv; cd venv
$ python3 -m venv flaskapp
$ source ~/venv/flaskapp/bin/activate
(flaskapp) $ pip install -U pip
(flaskapp) $ pip install flask uwsgi

nginx の設定ファイル

https://flask.palletsprojects.com/en/1.1.x/deploying/uwsgi/#configuring-nginx

flask で uwsgi を使う場合の nginx 設定ファイル例は上に載っているので、それを参考に。
アプリ名を nginx_yourapp とか your_application とかにしているが適当に変える。

nginx_yourapp.conf

server {
    listen 80;
    listen [::]:80;

    server_name hoge-machine.com;

    root /var/www/example.com;
    index index.html;

    location = /your_application { rewrite ^ /your_application/; }
    location /your_application {
        try_files $uri @your_application;
    }
    location @your_application {
        include uwsgi_params;
        uwsgi_pass unix:/tmp/your_application.sock;
    }
}

nginx の設定ファイルは /etc/nginx/sites-available 下に置いて、/etc/nginx/sites-enabled 下に
シンボリックリンクを張り、サービス再起動する。Permission 関係はよしなに。

$ mkdir -p ~/path/to/nginx_yourapp; cd ~/path/to/nginx_yourapp
$ vim nginx_yourapp.conf
(上記の設定ファイルを作る)
$ cp nginx_yourapp.conf /etc/nginx/sites-available/
$ ln -s /etc/nginx/sites-available/nginx_yourapp.conf /etc/nginx/sites-enabled/nginx_yourapp.conf
$ systemctl restart nginx

webアプリの準備

https://flask.palletsprojects.com/en/1.1.x/quickstart/#a-minimal-application

Flask の HelloWorld。

index.py

from flask import Flask

app = Flask(__name__)


@app.route("/")
def hello_world():
    return "Hello, World!"

uwsgi の起動コマンド

ソケットファイルは nginx の設定ファイルと合わせること
--chmod-socket=666 はパーミッション関連でこけたら
--mount はアプリパスと実行するスクリプト名:Flask appオブジェクト名を正しく指定する
--virtualenv は venv で作ったPython仮想環境を正しく指定する。

$ uwsgi -s /tmp/nginx_yourapp.sock --chmod-socket=666 --manage-script-name --mount /nginx_yourapp=index:app --virtualenv ~/venv/flaskapp

後はブラウザから http://<サーバのIPアドレス>/nginx_yourapp/ にアクセスすれば Hello World が表示される。

MQTTを使ってみよう

2019-11-21T23:48:51+09:00

MQTT(MQ Telemetry Transport)とは？

wikipedia

通信プロトコルの一種でPub/Sub型のデータ配信モデル。
軽量プロトコルのため、主にIoTの分野で使われていることが多いです。

Pub/Sub型

Pub/Sub型に関わるのは次の3者。

Publisher メッセージを出す人
Subscriber メッセージを読む人
Broker 配送業者(中継サーバ)

履歴の残らないLINE、という感じでしょうか。

中継サーバを立ててみよう

eclipse-mosquittoというMQTTサーバのdockerイメージが配布されています。

今回はホストの1883番ポートにmosquittoサーバを公開します。
さらにリバースプロキシの後ろに配置するため、nginxと同じnetwork(ここではdefault)に接続します。

docker-compose.yml(抜粋)

  mosquitto:
    image: eclipse-mosquitto
    hostname: mosquitto
    container_name: mosquitto
    ports:
      - "1883:1883"
    volumes:
      - ./mosquitto.conf:/mosquitto/config/mosquitto.conf
    networks: 
      - default

moquitto.conf(一部)

# ========================================================
# Default listener
# ========================================================
# Port to use for the default listener.
port 1883
# Choose the protocol to use when listening.
protocol websockets
# listener port-number [ip address/host name]
listener 9001

nginx.conf(listen 443)

 location /mqtt {
            proxy_pass  http://mosquitto:1883/;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
  }

クライアント(react)側実装

import PahoMQTT from "paho-mqtt";
const uuidv4 = require('uuid/v4');

//wssを利用する
const client = new PahoMQTT.Client(
    '******',443,uuidv4()
 );

 export const connect=()=>{    
    client.connect({
      userName: "******",
      password: "********",
      useSSL: true,
      onSuccess,
      onFailure
    });
    client.onMessageArrived = onMessageArrived;
    client.onConnectionLost = onConnectionLost;
}

const onSuccess=()=>{
    client.subscribe(TOPIC);
}
const onFailure=()=>{
    console.log('connect failed.')
}

export const onMessageArrived=(message)=>{
    console.log(message.payloadString);
}

export const send=(message)=>{
    client.send(TOPIC, message, 0, false);
}

function onConnectionLost(responseObject) {
    if (responseObject.errorCode !== 0) {
      connect();
    }
  }

アドベントカレンダー

crieitアドベントカレンダー「なんでも」

2日目に登板予定です。
MQTTを基礎技術に使ったアプリを作る予定です。

Oracle無料ティアでDjango+Nginx+uWSGIでサーバを立ててみる

2019-11-11T10:57:24+09:00

Oracle Cloudで常時無料サービスが開始されたので使ってみた。
構成は、Django+nginx+uWSGI+Oracle Database+Oracle Linux

以下の3つの環境を作ってみたので、その時の備忘録。

ローカルの開発環境
ローカルでDockerを使った開発環境
コンピュート・インスタンスでの本番環境

とりあえず、Djangoの雛形アプリにアクセスできるまでの簡易なので、
SSL対応などは省いてます。

Oracle Cloudの常時無料サービス(無料ティア)について

新しく常時無料で利用できるようになったサービスたち。
・Oracle Cloud無償ティア | オラクル | Oracle 日本

利用できるのは、以下のようなもの。

データベース ... 20GBを2つまで
コンピュート ... 仮想マシン。1/8 OCPU・1GBを2つまで
ストレージ ... 合計100GBの2つのブロック・ボリューム。10GBのオブジェクト・ストレージ

ほかにもロードバランサや監視・通知などある。

仮想マシンもデータベースも1アカウントにつき2つまでなので、
1サービスであれば、ステージング環境と本番環境を用意できそう。

とりあえずDBを作ってみる

トップ画面から。

名前とAdminのパスワードを設定する。
Always FreeもONにしておく。

「Autonomous Databaseの作成」をクリックすると、プロビジョンがはじまる。
プロビジョンが終わるとこんな感じに。

WebブラウザでDBにアクセスしてみる

SQL Developer Webからアクセスできる。

「DB接続」>「アプリケーション接続」>「SQL Developer Web」にある。
「アクセスURL」をコピーして、ブラウザに貼り付け。

ログイン画面が表示されるので、DBを作ったときのパスワードを入力。
アカウントは「admin」

ログインできるとこんな感じ

ローカルの開発環境を作ってみる

とりあえず、開発用にローカル環境でpython manage.py runserverできるようにする。
ローカルの環境はmacOS Mojave(10.14.6)

まずは、Djangoの雛形を作成する

# pythonのバージョンは3.7.3
$ python3 -V
Python 3.7.3

# ディレクトリの作成
$ mkdir sample
$ cd sample/

# 仮想環境の作成
$ python3 -m venv venv
$ source venv/bin/activate

# djangoのインストール
$ pip install --upgrade pip
$ pip install django

# djangoプロジェクトの作成
$ django-admin startproject myproject
$ cd myproject
$ python manage.py migrate

# 起動
$ python manage.py runserver

これでとりあえず、デフォルトのデータベース(SQLite)で立ち上がるとこまで完成。

ローカルでOracleDBを使えるようにする

Oracle Instant Clientのインストール

OracleDBを使うためには、Oracle Instant Clientが必要なので、
以下からダウンロードしてインストールする。
・Oracle Instant Client Downloads

Macだったので、「Instant Client for macOS (Intel x86)」の「Basic Light Package」を選択

## インストールするディレクトリを作成
$ sudo mkdir -p /opt/oracle

## インストールしたファイルを展開
$ sudo unzip ~/Downloads/instantclient-basiclite-macos.x64-19.3.0.0.0dbru.zip -d /opt/oracle

## ライブラリを参照できるように${HOME}/libにリンクを追加
$ mkdir ~/lib
$ ls -s /opt/oracle/instantclient_19_3/libclntsh.dylib ~/lib/
$ cp /opt/oracle/instantclient_19_3/lib* ~/lib/

環境変数にインストールした場所を設定

echo "export ORACLE_HOME=/opt/oracle/instantclient_19_3" >> ~/.bashrc
source ~/.bashrc

認証情報の配置

Oracle Cloudの「Autonomous Database」>「Autonomous Databaseの詳細」にある
「DB接続」からウォレットをダウンロードしてくる。

ファイル名は「Wallet_<データベース名>.zip」。
今回はデータベース名がsampleなので、Wallet_sample.zipとなる。

## 認証ファイルを配置するディレクトリを作成
$ mkdir -p /opt/oracle/instantclient_19_3/network/admin

## ダウンロードしたウォレットを展開して配置
$ sudo unzip ~/Downloads/Wallet_sample.zip -d ${ORACLE_HOME}/network/admin
Archive:  ~/Downloads/Wallet_sample.zip
  inflating: /opt/oracle/instantclient_19_3/network/admin/cwallet.sso  
  inflating: /opt/oracle/instantclient_19_3/network/admin/tnsnames.ora  
  inflating: /opt/oracle/instantclient_19_3/network/admin/truststore.jks  
  inflating: /opt/oracle/instantclient_19_3/network/admin/ojdbc.properties  
  inflating: /opt/oracle/instantclient_19_3/network/admin/sqlnet.ora  
  inflating: /opt/oracle/instantclient_19_3/network/admin/ewallet.p12  
  inflating: /opt/oracle/instantclient_19_3/network/admin/keystore.jks

cx_Oracle(pythonライブラリ)のインストール

Oracle Databaseのpythonライブラリをインストールする

$ pip install cx_Oracle

settings.pyの設定

settings.pyをOracleように変更。
NAMEには、TNS名のどれかを指定する。

今回は一番上のsample_HIGHを選択。

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.oracle',
        'NAME': 'sample_HIGH',
        'USER': 'admin',
        'PASSWORD': '',
    }
}

マイグレーションをもう一度実行してみて、接続できるか確認。

$ python manage.py migrate

マイグレーションが成功すると、Webブラウザ上のSQL Developerでも確認できる。

これで、とりあえず、開発できるようになった(´ω｀)

-ALLOWED_HOSTS = []
+ALLOWED_HOSTS = ["127.0.0.1"]

 ...

 STATIC_URL = '/static/'
+STATIC_ROOT = os.path.join(BASE_DIR, "static/")

+# for logging
+LOGGING = {
+    'version': 1,
+    'disable_existing_loggers': False,
+
+    'formatters': {
+        'standard': {
+            'format': "[%(asctime)s] %(levelname)s [%(name)s:%(lineno)s] %(message)s",
+            'datefmt': "%d/%b/%Y %H:%M:%S"
+        },
+    },
+    'handlers': {
+        'file': {
+            'level': 'INFO',
+            'class': 'logging.handlers.RotatingFileHandler',
+            'filename': 'django.log',
+            'maxBytes': 50000,
+            'backupCount': 2,
+            'formatter': 'standard',
+        },
+    },
+    'loggers': {
+        'django': {
+            'handlers': ['file'],
+            'level': 'DEBUG',
+            'propagate': True,
+        },
+    },
+}

2. staticディレクトリを作成&配置

manage.pyと同じ場所に作成し、
django-adminのcssとかを配置

$ mkdir static

$ python manage.py collectstatic

Docker用の資材を配置

# Docker用の資材の配置場所を作成
$ mkdir docker

# 資格情報の配置
$ mkdir docker/wallet
$ unzip ~/Downloads/Wallet_sample.zip -d docker/wallet/
Archive:  ~/Downloads/Wallet_sample.zip
  inflating: wallet/cwallet.sso      
  inflating: wallet/tnsnames.ora     
  inflating: wallet/truststore.jks   
  inflating: wallet/ojdbc.properties  
  inflating: wallet/sqlnet.ora       
  inflating: wallet/ewallet.p12      
  inflating: wallet/keystore.jks     

# NginxやuWSGIの設定ファイルは以下に配置
$ mkdir docker/conf
$ touch docker/conf/requirements.txt
$ touch docker/conf/myproject_nginx.conf
$ touch docker/conf/myproject_uwsgi.ini
$ touch docker/conf/uwsgi.service

# Dockerfireとdocker-compose.ymlを配置
$ touch docker/Dockerfile
$ touch docker-compose.yml

ディレクトリ的にはこんな感じ。

.
├── docker/
│   ├── conf/
│   │   ├── myproject_nginx.conf
│   │   ├── myproject_uwsgi.ini
│   │   └── uwsgi.service
│   ├── wallet
│   │   ├── ...
│   │   └── tnsnames.ora
│   ├── Dockerfile
│   └── requirements.txt
├── myproject/
│   ├── myproject/
│   │   ├── settings.py
│   │   └── wsgi.py
│   ├── static/
│   └── manage.py
├── venv/
└── docker-compose.yml

各ファイルの中身は以下の感じ。

docker-compose.yml

version: '2'

services:
  web:
    build: "./docker"
    volumes: # djangoアプリを/var/www配下にマウント
      - ./myproject:/var/www/myproject
    ports: # 80および8000ポートを開けておく
      - "80:80"
      - "8000:8000"
    # systemctlを使うので特権を有効にしておく
    privileged: true
    command: /sbin/init

docker/Dockerfile

# Oracle Cloud Infrastructureでも
# OracleLinuxを使うのでoraclelinuxのイメージを使う
FROM oraclelinux:7

### ENV
ENV ORACLE_HOME "/usr/lib/oracle/18.3"


### INSTALL ORACLE DATABASE
# oracle-instantclientを利用するために、2つリポジトリを有効化
RUN yum install -y oracle-release-el7 oracle-softwarecollection-release-el7
RUN yum install -y oracle-instantclient18.3-basiclite
RUN echo /usr/lib/oracle/18.3/client64/lib > /etc/ld.so.conf.d/oracle-instantclient.conf

RUN mkdir -p ${ORACLE_HOME}/network/admin
COPY wallet/* ${ORACLE_HOME}/network/admin/


### INSTALL PYTHON
# python3-develを利用するために、ol7_optional_latestを有効化
RUN yum-config-manager --enable ol7_optional_latest
RUN yum install -y python3 python3-devel gcc


### CREATE VIRTUAL ENV
RUN mkdir /var/www/
RUN mkdir /var/www/myproject

WORKDIR /var/www/

RUN python3 -m venv venv

# 作成した仮想環境(venv)にactivateする
ENV PATH="/var/www/venv/bin:$PATH"
COPY requirements.txt /var/www/
RUN pip install -r requirements.txt

#### INSTALL NGINX
RUN yum install -y nginx

COPY conf/myproject_nginx.conf /etc/nginx/conf.d/ 
RUN systemctl enable nginx

RUN chown -R nginx.nginx /var/www
RUN chmod 755 /var/www

### SETUP uWSGI Emperor mode
RUN mkdir /etc/uwsgi
RUN mkdir /etc/uwsgi/vassals
COPY conf/myproject_uwsgi.ini /etc/uwsgi/vassals

# uWSGIのログディレクトリを作成
RUN mkdir /var/log/uwsgi
RUN chown -R nginx:nginx /var/log/uwsgi

# uWSGIをサービスに登録
COPY conf/uwsgi.service /etc/systemd/system/
RUN systemctl enable uwsgi

docker/conf/requirements.txt

Django==2.2.7
cx-Oracle==7.2.3
uWSGI==2.0.18

docker/conf/myproject_nginx.conf

# the upstream component nginx needs to connect to
upstream django {
    # myproject_uwsgi.iniで設定したsocketファイルを指定
    # unix://
    server unix:///var/www/myproject.sock;
}

# configuration of the server
server {
    listen      80;
    # IPアドレスを指定。ローカルなので、127.0.0.1を設定
    server_name 127.0.0.1;
    charset     utf-8;

    # Django static
    location /static {
        alias /var/www/myproject/static;
    }

    # Finally, send all non-media requests to the Django server.
    location / {
        include     uwsgi_params;
        uwsgi_pass  django;
    }
}

docker/conf/myproject_uwsgi.ini

[uwsgi]

# Djangoプロジェクトのパスを指定
chdir           = /var/www/myproject
# Djangoプロジェクトのwsgi.pyを指定
module          = myproject.wsgi
# venvのパスを指定
home            = /var/www/venv
# process-related settings: master
master          = true
# maximum number of worker processes
processes       = 10
# socketファイルののパス
socket          = /var/www/myproject.sock
# socketファイルのユーザと権限を設定
chown-socket    = nginx:nginx
chmod-socket    = 666
# clear environment on exit
vacuum          = true
# logfile
logto           = /var/log/uwsgi/%n.log

docker/conf/uwsgi.service

[Unit]
Description=uWSGI Emperor
After=syslog.target

[Service]
User=nginx
Group=nginx

# 環境変数の設定
Environment="ORACLE_HOME=/usr/lib/oracle/18.3"
Environment="LD_LIBRARY_PAT=${ORACLE_HOME}/client64/lib:$LD_LIBRARY_PATH"
Environment="PATH=$PATH:${ORACLE_HOME}/client64/lib"

# EmperorモードでuWSGIを実行。venvにあるuwsgiを使う
ExecStart=/var/www/venv/bin/uwsgi --master --emperor /etc/uwsgi/vassals --die-on-term --uid nginx --gid nginx --logto /var/log/uwsgi/emperor.log
Restart=always
KillSignal=SIGQUIT
Type=notify
StandardError=syslog
NotifyAccess=all

[Install]
WantedBy=multi-user.target

Dockerを起動

# dockerを立ち上げ
$ docker-compose up -d

これでうまくビルドされて立ち上がれば、
http://127.0.0.1にアクセスできる。

myproject_nginx.confのserver_nameで、127.0.0.1を指定しているので、
http://127.0.0.1じゃないとDjangoアプリにアクセスできないので注意。

http://localhostだと、myproject_nginx.confの設定が適用されず、
nginxのデフォルトページが表示される。

よく使うログインとか停止とかはこんな感じ。

# コンテナにログイン
$ docker-compose exec web /bin/bash

# 停止
$ docker-compose stop

# 削除
$ docker-compose rm

# Dockerfile ビルド
$ docker-compose build

# Dockerfile ビルド(キャッシュなし)
$ docker-compose build --no-cache

# コンテナをせんぶ削除
$ docker rm `docker ps -a -q`

うまくいかないときにみるところ

以下の場所にログファイルが出力されるので見てみる。

/var/log/messages ... systemdのログ
/var/log/nginx/error.log ... nginxのエラーログ
/var/log/uwsgi/emperor.log ... uWSGI Emperorのログ
/var/log/uwsgi/myproject_uwsgi.log ... myproject_uwsgi.iniのログ
/var/www/myproject/django.log ... Djangoプロジェクトのログ

あとは、「パスが正しいか」「権限、オーナーが正しいか」などを見てみるといいかも。

コンピュート・インスタンスで公開してみる

仮想インスタンスの作成

ここから選択。

こんな感じで入力。
「パブリックIPアドレスの割当」を選択しておく。

ちゃんと「パブリックIPアドレスの割当」を選択していると、
ここにIPアドレスが表示される

デフォルトのユーザはopcなので、
こんな感じで、sshでログインできる。

$ ssh opc@

セキュリティルールを設定

HTTP(ポート80)でアクセスできるようにセキュリティルールを設定する
ただ、セキュリティルールを設定する場所は少しわかりにくい。。

仮想インスタンスの詳細にアクセスして、
「仮想クラウド・ネットワーク」を選択

左下に「ネットワーク・セキュリティ・グループ」を選択。
「ネットワーク・セキュリティ・グループの作成」を選択すると、追加できるようになる。

「名前」と「コンパートメント」に作成を設定

ルールの追加を以下のように設定して、「作成」をクリック

これで作成できたので、仮想インスタンスの詳細にもどって、
「ネットワーク・セキュリティ・グループ」の「編集」を選択

さっき作ったセキュリティグループを設定

環境構築

Dockerfileでやったような感じで、
Django+nginx+uWSGIな環境を構築してく。

DockerイメージのOracleLinuxとは違い、

リポジトリが最初から有効化されている
SELinuxが有効化されている

という感じなので、ちょっと変更が必要。

資材を仮想インスタンスに送る

Dockerのときに使った資材を仮想インスタンスに送る。

$ scp -r docker opc@:~/
$ scp -r myproject/ opc@:~/

送信したら、ログインして確認。

$ ssh opc@

$ pwd
/home/opc

$ ls 
docker  myproject

ログイン後のディレクトリ構成はこんな感じ

/home/opc
├── docker/
│   ├── conf/
│   │   ├── myproject_nginx.conf
│   │   ├── myproject_uwsgi.ini
│   │   └── uwsgi.service
│   ├── wallet
│   │   ├── ...
│   │   └── tnsnames.ora
│   ├── Dockerfile
│   └── requirements.txt
├── myproject/
│   ├── myproject/
│   │   ├── settings.py
│   │   └── wsgi.py
│   ├── static/
│   └── manage.py
├── venv/
└── docker-compose.yml

設定ファイルの変更

IPアドレスと127.0.0.1にしていたので変更する。

~/docker/conf/myproject_nginx.conf

  server {
-     server_name 127.0.0.1;
+     server_name ;
  }

~/myproject/myproject/settings.py

-ALLOWED_HOSTS = ["127.0.0.1"]
+ALLOWED_HOSTS = [""]

環境構築の実施

$ sudo -s

### INSTALL ORACLE DATABASE
$ yum install -y oracle-instantclient18.3-basiclite
$ echo /usr/lib/oracle/18.3/client64/lib > /etc/ld.so.conf.d/oracle-instantclient.conf

$ mkdir -p /usr/lib/oracle/18.3/network/admin
$ /home/opc/docker/wallet/* /usr/lib/oracle/18.3/network/admin/


### INSTALL PYTHON
$ yum install -y python3 python3-devel gcc


### CREATE VIRTUAL ENV
$ mkdir /var/www/
$ cp -r /home/opc/myproject /var/www

$ cd /var/www/

$ python3 -m venv venv

# 作成した仮想環境(venv)にactivateする
$ source venv/bin/activate
$ pip install -r /home/opc/docker/requirements.txt

#### INSTALL NGINX
$ yum install -y nginx

$ cp /home/opc/docker/conf/myproject_nginx.conf /etc/nginx/conf.d/ 
$ systemctl enable nginx

$ chown -R nginx.nginx /var/www
# $ chmod 755 /var/www

### SETUP uWSGI Emperor mode
$ mkdir -p /etc/uwsgi/vassals
$ cp /home/opc/docker/conf/myproject_uwsgi.ini /etc/uwsgi/vassals

# uWSGIのログディレクトリを作成
$ mkdir /var/log/uwsgi
$ chown -R nginx:nginx /var/log/uwsgi

# uWSGIをサービスに登録
$ cp /home/opc/docker/conf/uwsgi.service /etc/systemd/system/
$ systemctl enable uwsgi

##### ここから仮想インスタンス独自の設定

### Firewallの設定
# httpを追加する
$ firewall-cmd --permanent --add-service=http
# firewallを再起動して変更を反映
$ systemctl restart firewalld.service

### SELinuxの設定
$ restorecon -RF /var/www

### サービスの起動
$ systemctl restart nginx
$ systemctl restart uwsgi

一度、http://にアクセスして確認してみる。
エラーページが出ていたら、以下を実行

# 監査ログを確認
$ cat /var/log/audit/audit.log | grep nginx | audit2allow -m nginx
# ポリシーファイルを作成
$ cat /var/log/audit/audit.log | audit2allow -M nginx
# ポリシーファイルを適用
$ semodule -i nginx.pp

これで、http://にアクセスして、
Djangoの画面が表示されて、django-adminの画面が操作できればOK