最近の投稿 Recent posts

【資格】情報処理安全確保支援士試験（セキスペ）に合格しました。

作成日:2024年3月15日更新日:2024年3月15日

タイトルのとおりです。セキスペを取りました。登録セキスペにも申請済みで、来月から正式に登録セキスペとなる見込みです。

【AWS】AWS Solutions Architect - Associateに合格しました。

作成日:2023年12月3日更新日:2024年2月23日

ご無沙汰しております。IMAXおじさんです。

11.28〜12.1まで開催されていたAWS re:Invent 2023に参加してきました。これに行く前にAWSの資格を一つくらい取得しておきたいと思い立ち、AWS Solutions Architect - Associateを受験しました。結果は合格(760/1000)でした。次はDeveloper Associateの取得を目指します。

【AWS】VPSからAWSにサイトを移行した件

作成日:2023年11月1日更新日:2024年2月23日

お久しぶりです。IMAXおじさんです。

今日はこのサイトをさくらVPSからAWSに移行した話をします。現在はさくらVPSに戻しております。

元の構成(さくらVPS)に関して

元々はさくらVPSで小さめのサーバを借りてnginx + django + mysqlの構成でサイトを構成していました。詳細はこちらの記事に掲載しています。

この構成でやりたいことはだいたいできており、不満は全くなかったのですがお仕事でAWSを使い始めたこともあり、こちらに移行することにしました。

AWSでの構成に関して

個人サイトなのであまりお金がかかるのも困りものです。そこで、下の要求を満たすように構成を考えました。

月間予算20$ ~ 25$に収まるようにする
さくらVPSで構築していたコンテナをそのままEC2に移行するのではなく、S3やALBなどを使って、なるべくAWSの機能性を活かした構成にする
それぞれのサーバのログをS3に保管し、分析できるようにする

まだ全てを満たす構成にはできていませんが、現在は下のような形でデプロイをしています。

やりのこしていること

ログの分析
お部屋の気温分析アプリをIoT Core + IoT Analytics + Grafanaで実装

【資格】ネットワークスペシャリスト試験に合格しました！

作成日:2023年10月10日更新日:2024年9月16日

合格発表から時間が空いてしまいました。2023年4月にネットワークスペシャリスト試験を受験し、合格していました。

点数は午前2：8割、午後1：6割、午後2：8割といった具合で、落ちるなら午前１かなぁと思っていたところなんとか耐えていました。

次はセキスペとAWS SAAを受けようと思います。

HerokuにLINE webhookをデプロイする(heroku/line-bot-sdk/python3)

作成日:2023年10月10日更新日:2023年12月3日

HerokuにLINE Webhookをデプロイするまで

今回は無料で使えるホスティングサービスであるHerokuにLINE Webhookをデプロイするまでの手順を備忘録的に記します。

作りたいもの

実家でデジタル難民と化している祖母が他の家族からのLINEメッセージを見れるように、↓のようなシステムを作ろうと思い立ちました。

このシステムを作るにあたり、LINEメッセージを送ると自作のAPIにデータをPOSTするようなWebhookをつくりたいです。今回はゴールとして、まずはLINE bot(Python)に送ったメッセージをそのままLINEで返信してくるようなエコーボットをデプロイすることにします。

本記事の構成

前提(heroku/line developerのアカウント作成等)
Webhookの構成
line-bot-sdkについて
herokuへのデプロイ手順

1. 前提

1.1. herokuのアカウント作成

herokuの利用にはアカウント作成が必要です。今回は無料枠の範疇のことしかしないので、Freeアカウントで作成します。こちらからアカウントを作成することができます。

また、heroku CLIを使うためインストールが必要です。こちらの手順に従い、インストールしてください。

1.2. LINE Developerアカウントの作成

今回のwebhook作成に関しては、LINEbotが必要となります。LINEbotの作成にはLINE developerアカウントが必要となるため、アカウント登録をおこないます。こちらからアカウント作成をしてください。

2. webhookの構成

今回のwebhookを作成するにあたり、ローカル上で下記のようなフォルダ構成を作成します。

*/
|__main.py              # webhookの処理を記述する
|__requirements.txt  # 使用するライブラリの一覧
|__runtime.txt          # herokuで使用する言語の諸元
|__Procfile              # herokuで実行するコマンド
|__.env                   # herokuで使用する環境変数

2.1. `main.py`

main.pyにはline-bot-sdkを使って行う処理を記述することになります。詳細は3節で説明するため、ここでは説明を省きます。

2.2. `requirements.txt`

requirements.txtには今回使用するライブラリを記述します。これをプロジェクトフォルダに含めることで、デプロイ時に自動でライブラリをインストールしてくれます。

Flask==2.0.3
line-bot-sdk==2.2.1
requests==2.27.1

2.3. `runtime.txt`

runtime.txtにはherokuで使用するPythonのバージョンを記述します。その際、herokuが対応しているバージョンを選択しなければならないため、現在のherokuが何に対応しているかを確認するようにします。今回は以下の内容を記述します。一行のみです。

python-3.9.0

2.4. `Procfile`

Procfileはheroku上でデプロイ時に実行するコマンドを記述します。今回はmain.pyを実行することでサーバーを立ち上げたいので、下記の内容とします。

web: python3 main.py

2.5. `.env`

.envファイルはherokuの環境に登録したい環境変数を記述します。main.pyなどに直接記載したくない情報（例えばline-bot-sdkのシークレットキーなど）を記述し、herokuの環境に反映します。

3. `line-bot-sdk`について

今回は開発者公式が公開しているline-bot-sdkのサンプルプログラムを使用します。サイトはこちら(GitHub)から見れます。

元のサンプルプログラムはアクセストークンとシークレットキーをベタ書きしているため、この二つだけは環境変数から読み込むように変更を加えています。

from flask import Flask, request, abort
from linebot import LineBotApi, WebhookHandler
from linebot.exceptions import InvalidSignatureError
from linebot.models import MessageEvent, TextMessage, TextSendMessage
import os

# Flaskでwebhookを立ち上げ
app = Flask(__name__)

# アクセストークンとシークレットキーは環境変数から読み込む
YOUR_CHANNEL_ACCESS_TOKEN = os.environ["YOUR_CHANNEL_ACCESS_TOKEN"]
YOUR_CHANNEL_SECRET = os.environ["YOUR_CHANNEL_SECRET"]

line_bot_api = LineBotApi(YOUR_CHANNEL_ACCESS_TOKEN)
handler = WebhookHandler(YOUR_CHANNEL_SECRET)

@app.route("/callback", methods=['POST'])
def callback():
    signature = request.headers['X-Line-Signature']

    body = request.get_data(as_text=True)
    app.logger.info("Request body: " + body)

    try:
        handler.handle(body, signature)
    except InvalidSignatureError:
        print("invalid signatrue. please check channel info")
        abort(400)

    return 'OK'

@handler.add(MessageEvent, message=TextMessage)
def handle_message(event):
    line_bot_api.reply_message(event.reply_token, TextSendMessage(text=event.message.text))


if __name__ == "__main__":
    port = int(os.getenv("PORT"))
    app.run(host="0.0.0.0", port=port)

4. herokuへのデプロイに関して

ここまでのプログラムの準備ができたところで、herokuへのデプロイを行います。大まかな手順は下記の通りです。

heroku上でのプロジェクト作成
gitリポジトリの作成・登録
heroku環境変数の反映
herokuへのpush

4.1. heroku上でのプロジェクト作成

まずは、herokuの個人コンソールから「create new app」を選択し、新しいアプリケーションを作成します。

名前を選ぶように促されるので、適当な名前をつけます。「hogehoge.herokuapp.com」というURLを与えられますが、世界で一意な名前である必要があるため、適度に長い名前にしてください。

4.2. gitリポジトリの作成・登録

ローカルのプロジェクトをgitリポジトリとして登録し、herokuにpushします。

ローカルで

git init
git add *
git commit -m "first commit"

とし、まずはgitのローカルリポジトリを作成します。

次に、herokuのリモートリポを紐付けます。heroku CLIから以下を実行します。

heroku git:remote -a {自分のアプリの名前}

このままgit pushすると、環境変数を設定しないままビルドが始まってしまうので、git pushする前に.envファイルで設定した環境変数をherokuに反映します。

4.3. 環境変数の反映

heroku CLIを用いて、.envファイル内に記述した環境変数をherokuのアプリに反映します。プロジェクトディレクトリ内でheroku config:pushを実施します。成功すると「Successfully wrote settings to Heroku!」とログが出ます。

venv) hogehoge:~/Desktop/line-webhook-app$ heroku config:push
Successfully wrote settings to Heroku!

4.4. herokuへのpush

ここまで実施できたら、git push heroku masterでheroku上のリモートリポジトリにプロジェクトをpushします。 pushが成功すると自動でビルド→デプロイが行われます。

LINE botにメッセージを送って、全く同じ内容の返事が来れば成功です。

プロジェクト内でheroku logs --tailとすると、デプロイしたアプリのログを確認することができます。うまくLINE botが返事を返してくれなければ、このログを見てトラブルシュートを行います。

まとめ

これまでVPSをメインで使っていたので、herokuのようなPaaSを使えば無料で簡単にデプロイできるんだなと感心しました。

ソートアルゴリズムを真面目に実装する（応用情報技術者試験）

作成日:2023年10月10日更新日:2023年11月1日

タイトルの通り、ソートアルゴリズムを真面目に実装します。言語はPython、実装するソートアルゴリズムはクイックソート・ヒープソート・マージソートです。

ソートは基本的に標準ライブラリのsort関数に投げがちなので、内部がどうなっているかを気にすることがないかと思います。今回は応用情報技術者試験の対策も兼ねて、真面目にソートを実装します。なお、めんどくさいので昇順ソートしか実装しません()

参考文献

応用情報技術者試験合格教本(技術評論社)
プログラミングコンテストのためのアルゴリズムとデータ構造(マイナビ出版)
クイックソート
ヒープソート
マージソート(Qiita)
マージソート

クイックソート

クイックソートは、分割統治の考え方でソートを行うアルゴリズムです。

下記のような配列を考えたとき、その配列に対してpivotと呼ばれる軸を設定し、そのpivot未満の配列とpivot以上の配列に分割していきます。これを再帰的に繰り返すことで、整列済みの配列を得るアルゴリズムです。また、安定なソートではありません。

計算量

平均計算量は、O(NlogN)となります。具体的な計算量の導出はこちらが参考になりました。

ざっくり言えば、適切にpivotを選んだ場合上記の画像で示す通りpivotによる分割と結合はそれぞれ回数H = logNで抑えることができます。それぞれの高さに関して、N回比較が発生するので、計算量はO(NlogN)であるとわかります。

最悪計算量

ただし、予めソートされたデータに対して最大値/最小値をpivotとして取り続けた場合は最悪計算量がO(N^2)となります。

実装

A = list(map(int, input().split()))
l = 0
r = len(A) - 1

def quick_sort(tgt):
    tgt_len = len(tgt)
    if len(tgt) <= 1:
        return tgt

    pivot = tgt[0]
    left = []
    right = []

    for i in range(1, tgt_len):
        if tgt[i] <= pivot:
            left.append(tgt[i])
        else:
            right.append(tgt[i])

    return quick_sort(left) + [pivot] + quick_sort(right)

res = quick_sort(A)
print(res)

ヒープソート

ヒープソートはヒープの再構成がO(logN)でできることを利用したソートアルゴリズムです。ヒープの根が常に配列の最小値となっているので、ヒープの根をpop→ヒープを再構築...を繰り返し、popした順に配列を作ればO(NlogN)でソートできます。

ヒープに突っ込むため、安定なソートではないですが、常に計算量がO(NlogN)となります。

実装

ヒープを自力で実装し、ヒープからどんどんpopしていく方針を取ります。

class Heap:
    def __init__(self, arr:list):
        self.arr = []

        for item in arr:
            self.push(item)

    def push(self, x):
        self.arr.append(x)
        child = len(self.arr) - 1

        while child > 0:
            parent = (child - 1)//2

            if self.arr[parent] < x:
                break
            else:
                self.arr[child] = self.arr[parent]
                child = parent

        self.arr[child] = x

    def root(self):
        return self.arr[0] if self.arr else None


    def pop(self):
        if not self.arr:
            return None

        root = self.arr[0] 
        self.arr[0] = self.arr[-1]
        self.arr.pop()

        parent = 0
        smallest_index = parent
        heap_size = len(self.arr)

        while 2*parent+1 < heap_size:
            l = 2*parent+1  # 左の子
            r = l+1         # 右の子

            # 自分、左の子、右の子の中で、最小のものを選び取る
            if (r < heap_size) and (self.arr[parent] >= self.arr[r]):
                smallest_index = r

            if (l < heap_size) and (self.arr[smallest_index] > self.arr[l]):
                smallest_index = l

            # 自分が最小になった時点で、ヒープ化されたのでbreak
            if smallest_index == parent:
                break

            # 親と子を入れ替える
            self.arr[parent], self.arr[smallest_index] = self.arr[smallest_index], self.arr[parent]
            parent = smallest_index

        return root

def heap_sort(arr):
    heap = Heap(arr)
    N = len(arr)

    print(heap.arr)

    result = []
    for _ in range(N):
        result.append(heap.pop())
        print(heap.arr)

    return result

if __name__ == "__main__":
    sample = [1, 1, 2, -1, 100, 92]

    result = heap_sort(sample)

    print(result)  # -> [-1, 1, 1, 2, 92, 100]

マージソート

マージソートも、分割統治法の考え方を用いてソートを行うアルゴリズムです。下記画像のように、まず要素が一つになるまで分割を繰り返します。

その後、分割した配列を２つずつマージしていきます。このとき、分割した配列を結合する際に、昇順になるように入れていきます。各配列はソート済みであるので、それぞれ先頭のindexから順に比較していけば良いことになります。

計算量

こちらの説明がとてもわかりやすいです。

上の図で示した通り、分割とマージのプロセスはそれぞれH = logNで抑えられます。マージの際には、それぞれの分割のレイヤーでN回比較が走るので、結果的に計算量はO(2NlogN) = O(NlogN)となります。

実装

再帰的な実装を行います。（実は分割のところがO(N)かかっているのではないかという説があります）

def merge_sort(data):

    if len(data) <= 1: return data

    mid = len(data) // 2

    # 再帰的に分割していく
    left = merge_sort(data[:mid:])
    right = merge_sort(data[mid::])

    return merge(left, right)


def merge(left, right):
    result = []
    i, j = 0, 0

    # 配列の先頭が最小値になっているので、毎回比べながら追加していく
    while (i < len(left)) and (j < len(right)):
        if left[i] <= right[j]:
            result.append(left[i])
            i += 1
        else:
            result.append(right[j])
            j += 1

    # add the remainging part
    if i < len(left):
        result.extend(left[i:])

    if j < len(right):
        result.extend(right[j:])

    return result

if __name__ == "__main__":
    array = list(map(int, input().split()))

    res = merge_sort(array)

    print(res)

自作競プロジャッジサーバの構成について

作成日:2023年10月10日更新日:2023年11月1日

簡単な自作競プロジャッジサーバーを作った話をします。(競プロとは？：こちらを参照）デプロイしてから結構経つのに、詳細な構成に関して何も記事を書いていなかったので、ここらで文章に落とそうと思います。サーバは一時期まで公開していましたが、Dockerで実行環境を隔離しているとはいえ任意のコードが実行できてしまうのは怖いので最近は公開していません。

1. ジャッジサーバの構成に関して

ジャッジサーバ内のコンポーネント間の構成とデータフローを示します。

回答提出から正誤判定までのジャッジサーバ内での処理の流れ

回答者からコードが提出されると、一旦Djangoがそれを受け取ります。
DjangoはこれをRedis+Celeryで実装された非同期処理ジャッジキューに突っ込みます。その後、ユーザに対しジャッジ処理中である旨を示します。
ジャッジキューは順に提出コードの正誤判定を行ない、判定終了したコードに対し完了フラグを立てます。
ジャッジ完了後、各コードの正誤判定の詳細をユーザに返します。

2. 難しかったところ

非同期処理の実装

コードを提出してから、ジャッジが完了するまでにある程度時間がかかります。実行に時間がかかる場合やテストケースが多い場合は、POSTしてからページが表示されるまで何も表示されない状態になってしまいます。また、実行時間があまりに長い場合はブラウザにリクエストタイムアウトと判定されてしまいます。そのため、今回は下記のようなフローで非同期処理を実装することにしました。

バックエンドではジャッジがcelery+redisで実装されたFIFOキューを保持し、提出されたコードに順次正誤判定を行なっています。ジャッジ未完了の状態ではブラウザ更新を促し、ジャッジ完了の状態では結果を通知します。

TLEの検知

競技プログラミングにおいては、コードの実行時間が非常に重要です。多くの場合、2秒程度の実行時間内に問題を解けるコードを書く必要があります。制限時間内に解けなかったコードにはTLE(Time Limit Exceeded)判定が与えられ、不正解扱いとなります。

最初は簡単なジャッジサーバができれば良い程度に考えていたので、コードの正解・不正解しか判定しないロジックを書いていました。ところが、段々と完成度を追求したくなってくるもので、やはりTLEの判定がしたくなってきます。

色々実行時間を計測する術を検討しました。例えば、下記のようにコード実行前後で時刻を計測し、その差分を測るようなやり方です。

start = time.time()
ret = subprocess.run(cmd, shell=True, ...) #提出コードを実行
end = time.time()

timeTaken = end - start # 実行時間を計測

しかし、このやり方ではwhile True: passのような無限ループが発生した場合にTLE判定を出せなくなってしまいます。一定時間以上実行している場合には途中で実行を打ち切るような動作が必要になるわけです。

最終的にはコードを実行しているsubprocessモジュールで実行時間を計測し、オーバーした場合にTLE判定を出すようにしました。 subprocessモジュールには、実行時間を制限するオプションtimeoutがあるため、ここに実行制限時間の秒数を渡せば上記の問題に対応しつつTLEを判定できます。

# subprocessモジュールによるコードの実行
try:
    ret = subprocess.run(
        cmd, timeout=2, shell=True, stdin=fin, #  timeoutに制限時間を指定
        stdout=subprocess.PIPE, stderr=subprocess.PIPE
    )
except (CalledProcessError, TimeoutExpired) as e:
    if TimeoutExpired:
        tle += 1  # 実行時間が超過した場合はTLE判定を出す
        continue

    elif CalledProcessError:
        ...

3 今後の予定

フロントエンドをVue.jsで作り直す。
ajaxによる非同期通信を実装し、ユーザがブラウザ更新をする必要をなくす
対応言語を増やす(現在Java, C++, Python3, PyPy3に対応)
etc....

このサイト(www.teenytinybot.dev)の構成に関して

作成日:2023年10月10日更新日:2023年11月1日

最近更新しておりませんでした、IMAXおじさんです。この頃本サイトに色々機能を足していたので、そろそろ全体をまとめた構成図を作ろうと思い立ちました。

1. コンテナの構成について

本サイトはさくらVPS上にデプロイしています。当初はUbuntu Server上のネイティブで動かしていたのですが、お仕事でDockerをよく使うこともあり途中からDockerでのデプロイに切り替えました。

各コンポーネントの基本的な構成は以下となります。

OS：Ubuntu 18.04
仮想化：Docker
リバースプロキシ：Nginx 1.21.6
アプリバックエンド：Python3, Django 3.0
DB：MySQL 5.7
可視化ツール：Grafana 8.3.4
ログ監視：Splunk 8.2.5
ログ転送エージェント：UniversalForwarder(@Nginxコンテナ)

また、コンテナ間の関係とデータフローは以下の通りです。

2. Djangoで提供するアプリに関して

また、Djangoでは下記のアプリを作成して公開しています。

質問箱
- Djangoで初めて作ったWEBアプリです。
- 中の人に匿名で質問が送れます。line-bot-sdkと連携しており、質問がくるとBotからLINEで中の人に通知が来ます。
- (最近質問が来てなくてなんか寂しいので質問募集中です)
自宅の温湿度監視
- DjangoでRESTAPIを実装し、自宅のM5StackからAPI経由で気温・湿度・気圧をサーバに上げています。
- Grafanaで監視用ダッシュボードを作成し、公開しています。
技術ブログ
- 技術系の記事を書いていくブログページです。
- Markdown形式が使えるよう、Djangoプラグインであるmdeditorを入れています。
- また、コードはシンタックスハイライトが行われるよう、aceというライブラリを入れています。
- ↓こんな感じ
ログ監視
- また、自明に公開はしていませんが、Nginxのログを見ると公開サーバへの攻撃と思しきアクセスがかなり多いので、監視ツールとしてSplunkを入れています。
- 法人利用は有償ですが、個人利用であれば制限付きで一定期間は無償利用可能なようです。

3. 今後の予定

今後は以下のことに取り組みたいな〜と考えています。

AWSへのデプロイ（AWSできるようになりたい...）
elasticsearchとsplunkの比較
機械学習がバックエンドで動くWEBアプリ
Vue.js+Django RESTAPIで動く構成に（モダンなWEBの構成にしたい...）

【資格】応用情報技術者試験に合格しました

作成日:2023年2月5日更新日:2024年2月23日

応用情報に合格しました。午前午後ともに8割程度取れていました。次はNWスペシャリスト頑張ります。

基本情報技術者試験に合格しました

作成日:2022年8月30日更新日:2023年10月31日

本日基本情報を受けてきました． CBTに移行してからはスコアレポートが受験後すぐに見れるようになっているのですが，午前・午後どちらも6割を超えており合格していると思います．

(2022/07/18追記) 合格証書がお家に送付されて来ました。合格のようです。

仕事が思ったより忙しくあまり勉強の時間が取れませんでしたが，受かってよかったです．

次は応用情報取得を目指して勉強していこうと思います．

DjangoでMarkdown形式のエディタを実装，HTML形式で表示する

作成日:2022年8月30日更新日:2023年12月3日

Djangoでマークダウン形式のエディタを爆速で実装します．参考にしたサイトは以下です．

mdeditorとは

Markdown形式のエディタをDjangoに爆速で実装できるライブラリです．ここ実際に動作しているところはリンク先をご覧ください．結構有能なのでびっくりします．

環境

Ubuntu18.04 LTS(さくらVPS)
Python3.6.8
Django==3.0
django-mdeditor==0.1.18
Markdown==3.3.4

mdeditorの実装

まず，pipで必要なライブラリを入れましょう

pip install django-mdeditor
pip install Markdown

mdeditor自体の設定をしていきます．settings.pyに以下を追記します．

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'mdeditor' #これを追記
]
X_FRAME_OPTIONS = 'SAMEORIGIN'
MDEDITOR_CONFIGS = {
    'default': {
        'language': 'en',
    }
}

次に，models.pyを設定していきましょう．app内で定義するModelを以下のように定義します．普段使っているmodels.TextFieldが Markdown形式のオブジェクトになります

#models.py
from django.db import models
from mdeditor.fields import MDTextField

# Create your models here.
class Article(models.Model):
    title = models.TextField(max_length=200)
    content = MDTextField() #ここがMarkdown形式のTextFieldになる

    def __str__(self):
        return self.title

また，{project_name}/urls.pyに以下を追記します．

urlpatterns = [
    path('admin/', admin.site.urls),
    path('mdeditor/', include('mdeditor.urls')) #これを追記
]

admin.pyへの追記を忘れずに！

# admin.py
from django.contrib import admin
from .models import Article

# Register your models here.
admin.site.register(Article)

現時点でDjango Adminの管理画面からMarkdown形式で編集できるようになっているはずです．

Markdown_to_htmlの実装

次に，MarkdownをHTMLに変換していい感じに表示されるようにしていきましょう．先ほど定義したArticleモデルに次を追記していきます．

#models.py
from django.db import models
from mdeditor.fields import MDTextField
import markdown #ここを追記

# Create your models here.
class Article(models.Model):
    title = models.TextField(max_length=200)
    content = MDTextField() #ここがMarkdown形式のTextFieldになる

    def __str__(self):
        return self.title

    # 以下を追記
    def markdown_to_html(self):
        md = markdown.Markdown(
            extensions=['extra', 'admonition', 'sane_lists', 'toc']
        )
        html = md.convert(self.content)
        return html

このメソッドをHTML内のDjangoテンプレートから呼び出していきます．以下は関連する部分のHTMLコードです．

<!doctype html>
{% extends 'base.html' %}
{% load static %}

{% block content %}

{% for item in object_list %}
<article class="blog-post">
  <h4 class="blog-post-title">{{ item.title }}</h4>
  {{ item.markdown_to_html|safe }}
</article>
{% endfor %}
{% endblock %}

これだけだとコード整形のみが為されてお洒落なシンタックスハイライトがつきません．いい感じの見栄えにするために以下をHTML内に追記します．

<head>
  ...
  <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.15.6/styles/a11y-dark.min.css">
  ...
</head>

<body>
  ...
  <script src="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.15.6/highlight.min.js"></script>
  <script>hljs.initHighlightingOnLoad();</script>
</body>

これで完了です．試しにサーバーを立ち上げて確かめてみてください．

python3 manage.py runserver

技術系の備忘録を書き始めます．

作成日:2022年8月30日更新日:2023年10月15日

技術系の記事を書き始めることにしました．検索機能，月別アーカイブ，マークダウン，シンタックスハイライト等を実装したのでなんかいい感じに見れるようになると思います．試しにPython形式でかいたコードの見栄えを確認してみましょう．

def func(param):
    return param**2

いい感じですね．

pymodbusでModbus/TCPスレーブ(サーバー)を構築する

作成日:2022年1月19日更新日:2023年10月15日

お久しぶりです。IMAXおじさんです。今日は今までのWEB系の話とは少し変わって、PyModbusでModbus/TCPのサーバーを構築する話をします。

参考文献

HMSのサイト M-system技研のModbus/TCP通信仕様書

Modbus/TCPとは

Modbus/TCPとは、Modicon社(現Schneider Electric社)が1979年に策定した産業用Ethernetプロトコルです。主にPLCやリモートIOとの通信に使用される産業用Ethernetプロトコルであり、世界的なシェアとしては5%程度を占めています(2020年現在)。

Ethernet系フィールドバスのシェア

通信の概要

サーバー(フィールド側,  PLCやリモートIO)
xxx.yyy.zzz.100
    |
    |
クライアント(PC)
xxx.yyy.zzz.101

Modbus/TCPはサーバー/クライアント方式の通信プロトコルです。 PLCやリモートIOなどがスレーブ(==サーバー)、データ収集を行うPCなどがマスター(==クライアント)としてデータのやり取りを行います。名前の通り、各サーバーとクライアントがTCPでペイロードをやり取りします。物理レイヤーの仕様(端子形状など)は指定されておらず、あくまで通信のレイヤーのみの仕様となります。

ペイロードの仕様に関しては、下記のM-system技研発行の通信仕様書がよくまとまっており参考になります。

M-system技研 Modbus通信仕様書

PyModbusとは

PyModbusとは上記のModbusサーバー・クライアントを擬似的にPythonで構築できるライブラリです。対向機をわざわざ購入するとなると、数万円かかってしまいますが、PyModbusを使えば無料で手軽に対向機を用意できます。

PyPIのPyModbusページ

Modbus/TCPによる通信デモ

さて、Modbus/TCPの説明が終わったところで早速デモの構築に移りましょう。 PC上にPyModbusで構築したサーバーまでデータを取りに行くデモを構築します。

検証環境

PC: DELL Inspiron 7370
OS: Ubuntu20.04(LTS)
Python: 3.8.10
PyModbus: 2.5.3

Modbus/TCPスレーブ(サーバー)のPyModbusによる構築

PyModbusのサーバーを早速構築します。ローカルホストにサーバーを立てることにするため、特にIPアドレスは気にしなくてもよいです。実際にデバイス間通信を試したい人は、Ethernetポートを備えたデバイスを2個用意して固定IPを振ってあげるとよいかと思います。

今回はinput_registerに値を入れることにします。サーバーがレジスタ(input_register)に保持する値は、以下の通りとしましょう。

----------------------------
register1 |   int16
----------------------------
register2 |   float
register3 |   (32bit)
----------------------------

Modbusでは、1レジスタ=2byte(16bit)で扱われることに注意してください。なので、32bitのfloatなど16bitを超えるようなデータはレジスタをまたがって保持されることになります。

さて、このような値を返してくれるサーバーをPyModbusで構築していきます。まずは必要ライブラリのimportを。

# sample_server.py
from pymodbus.constants import Endian
from pymodbus.version import version
from pymodbus.server.asynchronous import StartTcpServer

from pymodbus.datastore import ModbusSequentialDataBlock
from pymodbus.datastore import ModbusSlaveContext, ModbusServerContext
from pymodbus.payload import BinaryPayloadBuilder

サーバー側でアクセス・送受信しているパケットの内容を確認するため、ログの設定をします。

import logging
FORMAT = ('%(asctime)-15s %(threadName)-15s'
          ' %(levelname)-8s %(module)-15s:%(lineno)-8s %(message)s')
logging.basicConfig(format=FORMAT)
log = logging.getLogger()
log.setLevel(logging.DEBUG)

次に、レジスタに入れる値を作っていきます。 PyModbusではpymodbus.BinaryPayloadBuilderを使ってペイロードのオブジェクトを作ることになります。

builder = BinaryPayloadBuilder(byteorder=Endian.Big) #ペイロードビルダーのインスタンスを作成。バイトオーダーは再現したいリモートIOの仕様に準ずること。

# 最初のint_16のペイロードを作成
builder.add_16bit_int(100)

# ２つ目のfloatのペイロードを作成
builder.add_32bit_float(123.45)

# ペイロードをModbusSequentialDataBlockへ変換
block = ModbusSequentialDataBlock(1, builder.to_registers())

# レジスタへの登録を行う
store = ModbusSlaveContext(ir=block, zero_mode=False)
context = ModbusServerContext(slaves=store, single=True)

最後に、サーバーを起動しておしまいです。

StartTcpServer(context, address=("0.0.0.0, 502")) # ローカルホストで起動

Modbus/TCPマスター(クライアント)のPyModbusによる構築

サーバーの構築はできたので、サーバーにためている情報を取りに行くクライアントを作ります。

Modbusではクライアントからのみ通信を始めることができます。クライアントから打てるリクエストにはいくつか種類(ファンクションコード)があります。詳しくはModbus/TCPの通信仕様書を見ていただきたいのですが、今回はファンクションコード4(FC4)を使います。 FC4はread_input_registersというリクエストになっており、その名の通りinput_registersの値を読み取るものになります。

(余談ですが、Modbus/TCPではread_input_registersで読まれるレジスタアドレスは300001から始まると決まっているようです。FC4なのに開始アドレスが3xxxなのは気持ちが悪い...)

サーバーの設定では、レジスタ3つにまたがってデータが溜まっているのでread_input_registersで3つ分レジスタを読んであげましょう。

from pymodbus.client.sync import ModbusTcpClient
from pymodbus.constants import Endian
from pymodbus.payload import BinaryPayloadDecoder

# Modbusクライアントのインスタンス。ローカルホストにサーバーが立っているので、アクセス先をlocalhostと指定。
client = ModbusTcpClient("localhost", port=502)

# FC4のread_input_registersでレジスタアドレス300001+0 ~ 300001+2を読み取る。
# 第一引数が開始アドレス(相対)、第二引数がレジスタ数
res = client.read_input_registers(0, 3, unit=1)

# 読み取ったレジスタ値をデコーダインスタンスへ渡す
# サーバー側がビッグエンディアン設定なので、こちらも合わせる。
decoder = BinaryPayloadDecoder.fromRegisters(res.registers, byteorder=Endian.Big)

# 最初のint_16bitをデコード
int16 = decoder.decode_16bit_int()

# 次のfloat_32bitをデコード
float32 = decoder.decode_32bit_float()

print(int16) # -> 100
print(float32) # -> 123.45...

これで、サーバーのinput_registersに溜まったデータをModbus/TCPで読み取ることができました。

まとめ

産業用ネットワーク難しい

nginx + uwsgi + django on dockerでサイトを公開する

作成日:2021年9月12日更新日:2023年10月15日

nginx + uwsgi + django on dockerでサイトを構築し，localhost上で公開するまでの解説です．

webサーバーの動き方に関して

djangoにはpython3 manage.py runserverで起動できる便利な開発サーバー機能が備わっています．しかし，本番環境ではこの機能は使わずに，apacheやnginxなどのwebサーバーを使用することが推奨されています．今回は，nginxを使用してdjangoアプリケーションデプロイすることにします．また，環境の移植性を考慮して，dockerを使用したデプロイを行います．

nginx + uwsgi + djangoの具体的な処理の流れはこちらで解説されていますので，ぜひ参照してください．非常に分かりやすく書かれており，これを読むだけである程度の設定はできてしまいます．

Setting up Django and your web server with uWSGI and nginx

簡単に図解すると，下の図のようにリクエストが流れていくことになります．

webクライアント -> nginx(80,443ポート) -> uwsgi(8000ポート) -> djangoバックエンド

nginxがwebサーバーとして機能しwebクライアントからリクエストを受け取る．
uwsgiがアプリケーションサーバーとしてnginxからのリクエストを受け取る．
uwsgiがdjangoを動かし，結果のレスポンスを返す

この構成を実現するため，以下ではnginx, uwsgi, djangoの各項目の設定事項を見ていきます．

`docker-compose.yml`の中身

まず，全体の見通しをよくするために，docker-compose.ymlの中身を紹介しておきます．

version: "3"

services:
  nginx:
    image: nginx:latest
    volumes:
      - ./nginx/conf:/etc/nginx/conf.d
      - ./nginx/uwsgi_params:/etc/nginx/uwsgi_params
      - ./django-project/myapp/static:/static
      - ./django-project/myapp/media:/media
    ports:
      - 8000:80
    environment:
      - LANG=C.UTF-8
      - LANGUAGE=en_US
    depends_on:
      - django-project
      - mysql

  django-project:
    build: ./django-project
    restart: always
    command: bash /init.sh
    tty: true
    volumes:
      - ./django-project/app:/myapp
      - ./django-project/init.sh:/init.sh
    environment:
      - DEBUG=False
      - LOCALHOST=localhost
      - DEPLOYHOST=#デプロイ先のドメイン名
    depends_on:
      - mysql
      - redis-server

  mysql:
    # mysqlに関する記述
    ....

各ファイルのフォルダ構成

project/
|__django-project/
|    |__myapp/
|    |    |__myapp/
|    |    |__static/
|    |    |__media/
|    |    |__manage.py
|    |__Dockerfile
|__nginx
|    |__conf/nginx.conf
|    |__uwsgi_params
|__mysql
|__docker-compose.yml

nginxの設定内容

まずnginxの設定を行います．ホストOS側で./nginx/conf/nginx.confを作成し，に以下の項目を書き足していきます．

upstream django {
    ip_hash;
    server django-project:8000;
}

server {
    listen 80;
    charset utf-8;

    client_max_body_size 75M;

    location /static {
        alias /static;
    }

    location /media {
        alias /media;
    }

    location / {
        uwsgi_pass django;
        include /etc/nginx/uwsgi_params;
    }
}

server_tokens off;

上記のポイントは，以下です．

upstreamでuwsgiサーバーを示すホスト名:ポート名を指定
listen 80で80番ポートをリッスン
location /static, location /mediaで静的ファイルの場所を指定．docker-compose.yml内でマウントした/static, /media内のファイルを探します．
location /でuwsgiをリクエストを流す先として指定します．uwsgi_paramsはここからコピペで問題ありません．

uwsgiの設定内容

uwsgiはdjangoと同じdockerイメージの中に入れます．./django-project/Dockerfile内に以下の内容を書き加えます．

FROM python:3.8-slim-buster

# djangoなど必要なライブラリをインストール
COPY ./requirements.txt /requirements.txt

# RUN source /venv/bin/activate
RUN python3.8 -m pip install --upgrade pip
RUN python3.8 -m pip install -r requirements.txt
RUN python3.8 -m pip install uwsgi # uwsgiを入れること

これでdjangoをuwsgiで動かす準備はできました．次にuwsgiでリクエストを待ち受けるために，コンテナ起動時に実行するシェルスクリプトを書いていきます．

#!/bin/bash

cd /myapp;
bash -c "python3 manage.py makemigrations";
bash -c "python3 manage.py migrate";
bash -c "python3 manage.py collectstatic --noinput"
bash -c "uwsgi --socket :8000 --module myapp.wsgi --py-autoreload 1s";

uwsgi(8000番ポート)で待ち受けることを最後の行で書き加えています．

djangoの設定内容

最後に，djangoの設定を行なっていきます．変更が必要なのは，/myapp/myapp/settings.pyのみです．

デバッグモードのON/OFFをdocker-compose.ymlから指定できるようにする． docker-compose.ymlのenvironmentでDEBUG=True/Falseと指定することでデバッグモードが変えられるように，環境変数の読み込み部分を追記します．また，djangoはDEBUG=Falseの際には外部からの通信を受け付けないので，ALLOWED_HOSTSにも環境変数の読み込みを追加します． DEPLOYHOSTの部分にデプロイするサーバーのホスト名を書きます．

# settings.py
# SECURITY WARNING: don't run with debug turned on in production!
is_debug_mode = os.environ.get("DEBUG")
DEBUG = (is_debug_mode == "True")
ALLOWED_HOSTS = [os.environ.get("LOCALHOST"), os.environ.get("DEPLOYHOST")]

nginxが静的ファイルをサーブできるように，staticファイルのルートを指定する． STATIC_ROOTとMEDIA_ROOTを指定することで，DEBUG=Falseの際に静的ファイルはnginxが直接サーブするようにできます．

# settings.py
STATIC_URL = '/static/'
STATICFILE_DIRS = [
    os.path.join(BASE_DIR, 'userctrl/static/'),
    os.path.join(BASE_DIR, 'contest_manage/static/'),
    os.path.join(BASE_DIR, 'ace-builds')
]
STATIC_ROOT = os.path.join(BASE_DIR, "static")

MEDIA_ROOT = os.path.join(BASE_DIR, "media")
MEDIA_URL = "/media/"

【Docker】alpineイメージをproxy環境下で使用する場合

作成日:2021年9月6日更新日:2023年10月15日

alpine linuxイメージをプロキシ環境下で使用する場合、様々な障壁に阻まれてコケることがあります。以下では、その回避策を列挙していきます。(問題の切り分けができていないので一部おかしいことを言っているかもしれません)

1. プロキシの環境変数への登録

Dockerfile内でプロキシを登録します。ここでRUN export http_proxy={プロキシ:ポート}とすると、なぜか環境変数に反映されておらずハマりました。解決策としては

ENV http_proxy=http://{プロキシのIPアドレス}:{ポート}/
ENV https_proxy=http://{プロキシのIPアドレス}:{ポート}/

とすることで環境変数に反映することができました。

2. レポジトリの追加

プロキシを経由する関係でapkレポジトリからライブラリを引っ張ってこれない場合があります。これは、デフォルトでapkがインデックスを探しに行くレポジトリURLがhttps://~となっている場合に起こります。下記のissueにはdl-cdn.alpinelinux.org does not support TLS at all. (中略) APK repositories should be http onlyとあります。そのため、/etc/apk/repositoriesにプレーンなhttpのURLの記述とする必要があります。

Githubのissue

すなわち、

RUN rm /etc/apk/repositories
RUN echo "http://cd-cdn.alpinelinux.org/alpine/v3.13/main" >> /etc/apk/repositories
RUN echo "http://cd-cdn.alpinelinux.org/alpine/v3.13/community" >> /etc/apk/repositories

とし、httpでapkのレポを探しに行きます。

docker上でdjango+mysqlで環境構築すると、access deniedエラーになる件

作成日:2021年8月13日更新日:2023年10月15日

Docker上でdjango+mysqlの環境構築をするとエラーになる件

環境

Macbook Air(M1)
Docker Desktop for Mac (ver.20.10.6)
Django == 3.0
Python3 (3.6-slim-buster)
MySQL 5.7

結論から言うと

MySQLイメージを使う場合は、{既存のDBファイルを含むローカルフォルダ}:/var/lib/mysqlとしてバインドするとハマります。新しい名前付きボリュームor空ディレクトリをバインドすることで、このエラーを回避できます。

やりたいこと

Pythonイメージ内でdjangoプロジェクトをビルドし、djangoからMySQLをDBとして使用したいです。その際、MySQLのデータを永続化させるために既にDB関連のデータを含んでいるローカルのフォルダ(下記のmysql/data_db)をマウントしようとしてハマりました。

はじめに試したディレクトリ構造は以下のようになっています。

my-docker-project/
|__django-project/
|     |__src/...
|     |__Dockerfile
|
|__mysql/
|    |__data_db/...
|    |__init_db/...
|
|__docker-compose.yml

また、docker-compose.ymlは下記の通りです。

version: "3"

services:
  mysql-db:
    image: amd64/mysql:5.7
    environment:
      - MYSQL_DATABASE=python_db
      - MYSQL_USER={ユーザー名}
      - MYSQL_PASSWORD={パスワード}
      - MYSQL_ROOT_PASSWORD=password
    volumes:
      - ./mysql/data_db:/var/lib/mysql
      - ./mysql/init_db:/docker-entrypoint-initdb.d
    privileged: true
    ports:
      - 3306:3306

  django-project:
    build: ./django-project
    restart: always
    command: bash -c "python3 /mysite/local_manage.py makemigrations && python3 /mysite/local_manage.py migrate && python3 /mysite/local_manage.py runserver 0.0.0.0:8000"
    ports:
      - 8000:8000
    volumes:
      - ./django-project/mysite/history:/mysite/history
      - ./django-project/mysite/media:/mysite/media
    depends_on:
      - mysql-db

以上の情報をもとに、django側のsettings.pyを以下の通りに設定しました。

# settings.py
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'python_db',
        'USER': 'root',
        'HOST': 'mysql-db',
        'PASSWORD': 'password',
        'PORT': '3306'
    }
}

症状

表記の通りの環境構築をDocker上で行いdocker compose up --buildすると、mysqlにアクセスできず以下のエラーに見舞われます。

django.db.utils.OperationalError: (1045, "Access denied for user 'root'@'192.168.32.3' (using password: YES)")

原因

調べて見ると以下の記事に行き当たりました。 stackoverflowの記事

上記の記事によると、 Do note that none of the variables below will have any effect if you start the container with a data directory that already contains a database: any pre-existing database will always be left untouched on container startup. とのことでした。すなわち、一度docker buildなどでDBファイルシステムが構成されてしまったディレクトリをバインドしようとすると、DBコンテナの初期化に失敗するらしいです。

対処法

docker-compose.yml内で/var/lib/mysqlに紐付けるフォルダを、docker compose up --buildする前に空にしておくことでうまくいきます。すなわち、

$ rm -r ./mysql/data_dbでdata_dbを削除
$ mkdir ./mysql/data_dbで再度ディレクトリ作成
$ docker compose up --buildでビルド

という手順を踏むことになります。これはうまくいくことを確認しました。

Django + Ace(django_ace) + DockerでオンラインPython実行環境を実装する

作成日:2021年7月14日更新日:2023年10月15日

タイトルの通り，Django + Ace + DockerでオンラインPython実行環境を実装します．一回で収まらないかもしれないので「その１」としています．

参考にしたサイト

環境

Django==3.0
django_ace==1.0.11
Python==3.6.8
Docker Pythonイメージ: python:3.7-slim-buster

構成の説明

Django: フレームワークとして使用
Ace: Webページ上でテキスト編集する際のシンタックスハイライト等に使用
django-ace: AceをDjango内のView定義から呼び出せるようにしたもの
Docker: 実行環境をサーバー内で隔離しないと悪意あるコードが実行できてしまうので，Dockerコンテナを使用

環境構築&必要ライブラリ群のインストール

$ python3 -m venv venv
$ source venv/bin/activate

$ pip install Django==3.0
$ pip install django-ace==1.0.11

プロジェクトの作成

$ django-admin startproject project
$ cd project
$ django-admin startapp editor
$ mkdir history #実行するスクリプトの保存先

この時点で，ディレクトリは以下のような構成になっているはずです．

project/
　├ editor/
　├ project/
　├ history/
　└ manage.py

フォームビューの作成

エディタ部分を実装するために，フォームビューを実装します． CDN等で提供されるAceを埋め込んで利用しても良いですが，ここではdjango-aceを使用します．

#forms.py
from django import forms
from django_ace import AceWidget

class EditorForm(forms.Form):
    code = forms.CharField(
        widget = AceWidget(
            mode="python",
            theme="twilight",
            width="100%"
        )
    )

EditorFormを作成したら，Viewを追加していきます．下記のコードでは，index.htmlをテンプレートとして，HTML中のformから実行コードを取得します．取得したコードは，historyフォルダ内に保存され，dockerコンテナ内で実行されます．

start_docker(code): dockerコンテナに実行するコードを投げ，実行するコード．
Home(views.FormVIew): html内のフォームから取得したコードを，start_dockerに投げます．

# views.py
from .forms import EditorForm

FILE_DIR = os.path.join(settings.BASE_DIR, 'history')
DOCKER_CMD = 'docker run -i --rm --name tmp_container -v {}:/usr/src/myapp -w /usr/src/myapp python:3.7 python {}'

def start_docker(code):
    # dockerコンテナ内でコードを実行する
    file_name = '{}.py'.format(datetime.datetime.now().isoformat())
    file_path = os.path.join(FILE_DIR, file_name)

    with open(file_path, 'w', encoding='utf-8') as file:
        file.write(code)

    cmd = DOCKER_CMD.format(FILE_DIR, file_name)
    ret = subprocess.run(
        cmd, timeout=15, shell=True,
        stdout=subprocess.PIPE, stderr=subprocess.STDOUT
    )

    return ret.stdout.decode()

class Home(generic.FormView):
    template_name = 'index.html'
    form_class = EditorForm
    sucess_url = reverse_lazy('home')

    def form_valid(self, form):
        #　送信ボタンで呼ばれる
        code = form.cleaned_data['code']
        output = start_docker(code)
        context = self.get_context_data(form=form, output=output)
        return self.render_to_response(context)

<!--index.htmlの一部のみ抜粋-->
<head>
....
{{ form.media}}
</head>

<body>
....
<div class="col-12">
    <form action="" method="POST">{% csrf_token %}
        {{ form.code }}
        <button class="btn btn-primary" type="submit">Run</button>
    </form>
</div>

<div class="col-12">
    <label for="exampleFormControlTextarea1" class="form-label">実行結果</label>
    <textarea class="form-control" id="exampleFormControlTextarea1" rows="3" disabled>{{ output }}</textarea>
</div>
...
</body>

以上をいい感じにまとめると，下記のようなコード編集画面が現れます．(あとで追記)

About

IMAXおじさんが(主に)技術系記事を備忘録として残していくブログです．

最近の投稿 Recent posts

【資格】情報処理安全確保支援士試験（セキスペ）に合格しました。

【AWS】AWS Solutions Architect - Associateに合格しました。

【AWS】VPSからAWSにサイトを移行した件

元の構成(さくらVPS)に関して

AWSでの構成に関して

やりのこしていること

【資格】ネットワークスペシャリスト試験に合格しました！

HerokuにLINE webhookをデプロイする(heroku/line-bot-sdk/python3)

HerokuにLINE Webhookをデプロイするまで

作りたいもの

本記事の構成

1. 前提

1.1. herokuのアカウント作成

1.2. LINE Developerアカウントの作成

2. webhookの構成

2.1. main.py

2.2. requirements.txt

2.3. runtime.txt

2.4. Procfile

2.5. .env

3. line-bot-sdkについて

4. herokuへのデプロイに関して

4.1. heroku上でのプロジェクト作成

4.2. gitリポジトリの作成・登録

4.3. 環境変数の反映

4.4. herokuへのpush

まとめ

ソートアルゴリズムを真面目に実装する（応用情報技術者試験）

参考文献

クイックソート

計算量

最悪計算量

実装

ヒープソート

実装

マージソート

計算量

実装

自作競プロジャッジサーバの構成について

1. ジャッジサーバの構成に関して

2. 難しかったところ

非同期処理の実装

TLEの検知

3 今後の予定

このサイト(www.teenytinybot.dev)の構成に関して

1. コンテナの構成について

2. Djangoで提供するアプリに関して

3. 今後の予定

【資格】応用情報技術者試験に合格しました

基本情報技術者試験に合格しました

DjangoでMarkdown形式のエディタを実装，HTML形式で表示する

mdeditorとは

環境

mdeditorの実装

Markdown_to_htmlの実装

技術系の備忘録を書き始めます．

pymodbusでModbus/TCPスレーブ(サーバー)を構築する

参考文献

Modbus/TCPとは

通信の概要

PyModbusとは

Modbus/TCPによる通信デモ

検証環境

Modbus/TCPスレーブ(サーバー)のPyModbusによる構築

Modbus/TCPマスター(クライアント)のPyModbusによる構築

まとめ

nginx + uwsgi + django on dockerでサイトを公開する

webサーバーの動き方に関して

docker-compose.ymlの中身

各ファイルのフォルダ構成

nginxの設定内容

uwsgiの設定内容

djangoの設定内容

【Docker】alpineイメージをproxy環境下で使用する場合

1. プロキシの環境変数への登録

2. レポジトリの追加

docker上でdjango+mysqlで環境構築すると、access deniedエラーになる件

Docker上でdjango+mysqlの環境構築をするとエラーになる件

環境

2.1. `main.py`

2.2. `requirements.txt`

2.3. `runtime.txt`

2.4. `Procfile`

2.5. `.env`

3. `line-bot-sdk`について

`docker-compose.yml`の中身