コンテンツにスキップ
4月末からの大型連休につきまして、平日は通常通り出荷いたします。
4/27~4/29まで土日祝でお休み、4/30~5/2までは通常営業、5/3~5/6まで土日祝でお休みです。
4月末からの大型連休につきまして、平日は通常通り出荷いたします。
4/27~4/29まで土日祝でお休み、4/30~5/2までは通常営業、5/3~5/6まで土日祝でお休みです。
古いFlask + SQLIteなウェブアプリ "EAGLE ".brd" file panelizer" を移設した話

古いFlask + SQLIteなウェブアプリ "EAGLE ".brd" file panelizer" を移設した話

こんにちは。ECシステム開発チームのいまづです。
普段は社内の通販システム周りに生息しています。

最近、Litestreamをいじっているところに古いウェブアプリどうにかならん?という話が舞い込んできたので、対応してみたお話をします。

 

「EAGLE ".brd" file panelizer」ってサ終なの?

体調崩した休み明け、社内のSlackにこんな感じのメッセージが。

「EAGLE ".brd" file panelizer」ナニソレ知らない。(これでした→ https://eagle-panelize.switch-science.com/ )

聞けば、2014年くらいに大ボスが作ってサービス提供しつづけているものらしい。
ホストしているPythonバージョンがあがってくるにつれ、対応していないものだから動かなくなっている模様。

環境は移していいので、時間があるときになおしてくれと。なるほど。

 

どんなものなのか見てみる

ソースコードはGitHub上においているとのことなので、とりあえず中身を拝見。

「基板の面付け」(当方ソフトウェア開発担当につき、あんまりわかっていない)をするユーティリティだとのことなんですが、やってることといえば、XMLファイルを編集して、元の基板データを縦横に指定数貼り付けた新しいXMLファイルを作成するということ。

フレームワークにはFlask 、あと実行記録的な用途でSQLiteを使っている。
ウェブアプリとしてはとてもシンプル。

実際の環境ではWSGIつかって動かしている模様。


Python3対応


コード量も大したこと無いし、とてもシンプルに書かれていたこともあり、Python3移行自体は大して問題なかった。

やったこととしては、おおよそこんなところ。

  • 標準パッケージの変更に追従。 `configparser` とか
  • flaskのパッケージの構造変更( `markupsafe.Markup` が `flask` から追い出されたやつ)
  • `hashlib` 対応。
  • `except` 句の書き方。
  • `str` `bytes` 使い分け対応。


(今回Pythonの `buffer` 型が使われているコードを初めて見た気がする。)


どこにデプロイするか問題


作りは単純なので、どこでも動かせそうといえばそうなんですが、今の社内の環境的には「とりあえず細かいアプリをデプロイする常時かどうしているウェブサーバー」的なものはほぼなくなっているので、

  • 手間をかけず
  • できるだけコストもかけず
  • それなりに安定して


動かせる環境にデプロイできる状況を作りたいところ。

Docker化はするとして、社内のシステムのほとんどはAWSを使っているので、できればAWSで楽がしたい。

SQLite3が使われているので、これをどうにかする必要があるけど、RDS使うまでやりたくないし、まして他のものに対応するほど手間もかけなくない。

採用した構成

 こうしました。


デプロイを極力単純にしたいので、Docker化は必須でしょうと。
Python環境を閉じ込めるのと、後述のLitestreamを扱うところも組み込み。

LitestreamにはSQLite3のデータベースファイルをS3上にレプリケートする機能があります。これを使って、イメージの起動時にレプリカを取得、ウェブアプリの実行中はS3にレプリケート、という構成にすれば(インスタンスの数が1に限られることにはなりますが)今回の用途・規模には合いそう。

こんな感じの小規模構成からすると、ECSでFargateで、というのはちょっとめんどくさくってイヤでした。

AWS Lightsailなら最小構成(nano / 1ノード)なら $7/月と、許容範囲かなと。
プライベートイメージはawscliでデプロイできますし。


やってみて


Litestreamは特に問題なく動作している模様。ただ、S3にアクセスさせるにあたってアクセスキーの情報を渡してあげる必要がありました。

Lightsailのデプロイ時に指定する設定ファイルに環境変数を書けばよいのだけど、GitHub Actionsの中でファイル作成して実行するような形にするのが良いかな、などと考えているところです。

使いどころは限られるだろうけど、ちょっとしたところでは割とLitestream刺さるところがあるのでは、という印象です。

AWS Lightsailは実は今回始めて使ったのですが、お手軽で良いですね。規模が大きくなってくるようだとFargateなどで真面目に環境作らないとならないかとは思いますが、小さいアプリを手っ取り早く動かすには手数が少なくて良かったです。

 

 

 


 

システムエンジニア募集中です!

興味のある方はぜひカジュアル面談へ!お待ちしています。

前の記事 Mini Marvels: ESP32 & AS7331 Supercharge Your IoT Ideas!