GAミント至上主義

Web Monomaniacal Developer.

Django&Python3で一時ディレクトリだけで複数ファイルのZIP圧縮を済ませる

Djangoでフォームで受け取った複数のファイルを、パスワード付きZIPで固めてmodelに保存したかった。

Pythonの標準モジュールzipfileではpass付きを展開はできても、作成はできないのでpyminizipを使う。

ファイル名と、中身を別々に渡せれば一時ファイルでもいいんだけど、pyminizipにはファイルパスのリストを渡す必要がある。


その際、一時ファイルを使ってしまうと、ファイル名がランダム文字列になってしまうので、フォームから送られてきたファイル名を維持するために一時ディレクトリを使い、その中にアップロードされた名前でファイルを作成する。

with文を使ってるので、closeとかの処理が省けるし、ブロックを抜けた時にすぐ消えてくれるので気持ちがいい。


コードは実コードをサンプル用に手を入れてるので動かなさそう。


views.py

import os
import pyminizip
from tempfile import TemporaryDirectory
from .models import ZipFile


def index(request):
    if request.method == 'POST':
        form = MailForm(request.POST, request.FILES)
        if form.is_valid():
            # djangoのフォームからファイル取り出す
            received_files = request.FILES.getlist('file_field')
            password = "pass"
            temp_file_list = []
            with TemporaryDirectory() as temp_dir:
                # ZIPファイルの名前には最初のファイルの名前を拡張子zipにしてつかう
                zip_path = os.path.join(temp_dir, os.path.splitext(received_files[0].name)[0] + '.zip')
                for f in received_files:
                    # pyminizipに渡す時に一時ファイルのままだと、名前がランダムな感じで良くないので
                    # request.FILESから取り出すして使う
                    temp_path = os.path.join(temp_dir, f.name)
                    with open(temp_path, "wb") as tmp_f:
                        tmp_f.write(f.read())
                    temp_file_list.append(temp_path)
                pyminizip.compress_multiple(temp_file_list,
                                            zip_path,
                                            password, 2)
                temp_zip = File(open(zip_path, "rb"))

        # djangoのmodel
        zipfile = ZipFile()
        # zip_pathのままにしてしまうと、/tmp/xxxの階層つきでZIPに入ってしまうのでファイル名だけ渡す
        zipfile.file_field.save(os.path.basename(zip_path), temp_zip)
        zipfile.save()

Django1.10 QUICKSTART-BOOK with Python3: 作りながら学ぶDjangoアプリケーション開発

Django1.10 QUICKSTART-BOOK with Python3: 作りながら学ぶDjangoアプリケーション開発

Django×Python (LLフレームワークBOOKS)

Django×Python (LLフレームワークBOOKS)

1日で理解するDjango超基礎入門

1日で理解するDjango超基礎入門

mastodonのアップデート時にrails assets:precompileが、Compiling webpacker assets で止まる

フルGCPで運用している社内用インスタンス( http://mstdn.bizocean.co.jp )でオリジナルイラストができたのでアップデートしようとしたら、

Binary found at /mastodon/node_modules/node-sass/vendor/linux_musl-x64-48/binding.node
Testing binary
Binary is fine
node-sass@4.5.2 /mastodon/node_modules/node-sass
Done in 37.82s.
Webpacker is installed 🎉 
Using /mastodon/config/webpack/paths.yml file for setting up webpack paths
Compiling webpacker assets 

で止まってしまった。

検索したらどうやらメモリ不足らしい

Rebalance Allocation fails when compiling assets · Issue #2883 · tootsuite/mastodon · GitHub


そういえば先週サーバー代をケチるために、n1-standardからsmallにしたのを思い出した。その時は問題なく終わっていた。

たかが静的ファイルの準備ごときでサーバーをスケールアップさせる必要があることに苛立つ。smallといえども1.7GBあるのに。RailsのせいなのかRubyのせいなのか。

せっかくDockerのコンテナを使って、少ないリソースでたくさんの仮想マシンを動かすことができたのに、中身がメモリを喰うのでは話にならない。

oceanusで使っているコンテナとくらべて、GKE上でのコンテナの立ち上がりも遅いので、デプロイや開発スピードにも影響がでる。

PythonDjangoでは管理系コマンドで待たされたり、メモリ不足になったことはないので、個人的にRubyRailsはやっぱり重い、という印象をmastodonの運用で上書きすることとなった。

Google App Engine + Django +Cloud SQLで社内用短縮URLサービスを作った

データ基盤のoceanusで、Google App Engineを使った短縮URLサービスを追加した。

脳内でもんもんと設計をし、手を動かし始めてから完成まで3日ぐらい。

ソースコードは下記。

github.com

公開しているけど、短縮URLの作成画面は社内の人間のみで、ログイン必須。

作成すると下記のような、大文字小文字英数6字のURLが作られる。


https://s.bizocean.jp/Neas1j


画面はDjangoの管理画面を除くと2画面。


単発で作るフォームと

f:id:uyamazak:20170515141021p:plain

メールマガジンの文面などのURLを一括で変換&置換するもの

f:id:uyamazak:20170515141048p:plain

独自の短縮URLサービスが必要な理由

なぜ、巷にはたくさんの短縮URLサービスがあるのに、oceanus専用の短縮URLが必要かというと、メールマガジンなどに貼るリンクを誰が踏んだかのデータも一元管理したかったから。

ただ他のURLに飛ばすだけでなく、リダイレクト前にoceanusのAPIにデータを送っている。

一部のパラメーターは追加が可能で、例えばユーザーIDが12345のユーザーには下記のようにして送れば、特定が可能になる。

https://s.bizocean.jp/Neas1j?uid=12345

短縮URLアルゴリズム

短縮URLサービスはシンプルなサービスゆえに、いろいろと作り方がWEB上で見つかる。

今回はDjango短縮URLを作るチュートリアルが見つかり、URLの作成部分、HTML部分はかなり流用させていただいた。


Django Tutorial – Building URL Shortener with Djangohellocoding.wordpress.com

Google App Engineを使う理由

下記の理由から、他で使っているGoogle Container Engine(GKE)ではなく、GAEのSTANDARD ENVIRONMENTを利用した。

  1. メールマガジンに貼ったりするため、アクセスの偏りが大きい
  2. シンプルなサービスなので必要なライブラリが少ない
  3. 今後の機能拡張も必要ない

1に関して、bizoceanでは200万以上の会員にメルマガを配信しているので、配信直後にアクセスが集中する。GKEでもオートスケールはできるが、MAXがどのくらい必要なのかとか、POD単位、クラスタ単位なのかを考えたり、指標をどうするかなど考えたり設定することが多い。でもGAEであればいい感じに勝手にスケールしてくれるので心配が少ない。

2に関して、今回はDjangoMySQLが使えれば十分なことがわかっていたので、pipなど外部のライブラリの追加も必要なかった。正確にはpythonのrequestsが使いたかったが、面倒だったのでurllibとか標準ライブラリで済ませた。Python3を使いたいとか、大きめのライブラリを使いたい、RedisとかRabbitMQが必須、となればGKEを使ってたと思う。FLEXIBLE ENVIRONMENTであればPython3.4が使えるけど、中途半端だし、Dockerイメージ使うのであればGKEでいいじゃんという気になる。

3は、どんどん拡張していく予定であれば、2の理由等から難しいけど、変換とリダイレクト、ユーザー認証だけ、と決まっていたのでGAEで十分だった。


また現在、oceanusのWEB APIであるarmsはフレームワークFalconを使っており、こちらはCythonが必要だし、シンプルなフレームワークなため、Djangoの用にユーザー認証や管理画面を作るのは面倒だったというのもある。

Djangoを使う理由

個人的にDjangoの経験があったことと、ドキュメントが充実していること、ユーザー認証を簡単に実装できること。

下記の公式チュートリアルを動かせることができれば、あとは継ぎ足しですぐ完成できる。

Running Django on App Engine Standard Environment  |  Python  |  Google Cloud Platform

GAEでDjangoを動かす、公式ドキュメントがあるし、上記の短縮URLみたいにWEB上にDjango関係のドキュメントは非常に充実している。

問題としてはちょっとバージョンが古い(現在1.11があるけど1.9まで)ことぐらい。



ユーザー認証が必要で、シンプルで、実質無限なスケールを必要なサービスには、手軽なGAE+Djangoがおすすめです。

Django1.10 QUICKSTART-BOOK with Python3: 作りながら学ぶDjangoアプリケーション開発

Django1.10 QUICKSTART-BOOK with Python3: 作りながら学ぶDjangoアプリケーション開発