Skip to content

Latest commit

 

History

11 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 

Repository files navigation

サーバレスアプリケーション作成練習用ディレクトリ

#2025.04.29 githubにリポジトリ作成。環境構築を開始。 書籍では仮想環境にpipenvを使用しているが、pyenvかvenvで検討中。 -> pyenvはpythonのバージョン管理用のツールでvirtualenvの間違いであった。 結局、書籍通りにPipenvを使用することとする。 PipenvはPipfileとPipfile.lockを使用してプロジェクトの依存関係を管理する。

Pipenvの使い方: プロジェクトディレクトリ内で"pipenv install"を実行すると、 仮想環境が作成されPipfileが自動的に作成される。 書籍では、"pipenv --python 3.8"でpythonバージョンを指定する手順があったが、 仮想環境作成の手順を実行してからでないとエラーとなる。

その他のコマンド "pipenv install パッケージ" 仮想環境にパッケージをインストールする。プロジェクトの依存関係がPipfileに追加される。 "pipenv install パッケージ --dev" 開発中にのみ必要なパッケージを--devを付けてインストールする。 "pipenv shell" 仮想環境のアクティベート "exit" 仮想環境の終了 "pipenv uninstall パッケージ" パッケージのアンインストール "pipenv lock" 依存関係のロック

その他の使い方 ・pythonのバージョン指定 "pipenv --python 3.8" ・スクリプトの実行 Pipfileにスクリプトを定義できる。 [scripts] test = "pytest"

実行コマンド pipenv run test ・パッケージのセキュリティチェック "pipenv check" ・グラフ表示 "pipenv graph"でパッケージ感の関係を視覚的に表現できる。 ・本番環境でのパッケージインストール "pipenv install --ignore-pipfile"コマンドを実行することで、 Pipfile.lockに基づいてパッケージインストールが行われる。 開発環境と本番環境の一貫性を保つのに有効。

pipenvで仮想環境を構築しようとしたが、Flaskのインストール時にPipfile.lockのロックを失敗する事象が発生。 pipやpyenvのPATHがアナコンダとかと競合しあっているようであった。 そのため、Pipenvを一旦アンインストールし、anacondaのPATHを消去してインストールし直した。 その際Pythonのパスがシステム由来のPATHとなったことでインストールできない旨のエラーが発生するようになった。 PythonをPyenv環境のPython3.8を使用してインストールすることで正常に動作するようになった。 Flaskのインストールまで行った。

#2025.04.30 Flaskによるページの雛形作成 pythonでHello Worldを実行したが、標準モジュールの欠如で実行できなかった。 必要なモジュールをaptでインストールした後、Pyenvでpython3.8.20の再インストールを行った。 再インストール後は正常にブラウザに表示された。 一つのファイルでページ表示を行っていたが徐々に分割し、設定ファイルであるconfig.pyと表示専用のvewディレクトリに分割された。

#2025.05.01 CSSライブラリとしてBootstraoを使用し、記事閲覧ページのビュー作成を行った。 Bootstrapの機能として、ブラウザサイズに合わせてナビゲーションバーがハンバーガーメニューに変わる。

#2025.05.03 トップページの記事一覧表示ページを作成。 htmlファイルの共通部分をまとめたレイアウトファイルを作成。 新規投稿画面作成。 編集画面作成。 DBとしてDynamoDBを用意する。ORMとしてPynamoDBをインストールする。 ビュー内の仮データをDynamoDBから取得するように変更。 ローカルにDynamoDBを導入するために色々準備。 Java SE Development Kit 24.0.1 downloads DynamoDBをターミナル上で実行できた。

#2025.05.04 Flask-Scriptを用いて、PynamoDBモデル定義をデータベースに反映させてテーブル作成する。 Flask-Scriptを使用しようとしたが、現在ではサポートされていなかったためFlask-CLIを使用する構成に変更した。

DynamoDB-local起動コマンド: java "-Djava.library.path=./DynamoDBLocal_lib" -jar DynamoDBLocal.jar -sharedDb

DynamoDB-localブラウザ管理画面起動コマンド:dynamodb-admin

ここまでをGithubにプッシュする。以降はブランチ戦略も合わせて勧めていく。 次はログイン機能の作成である。

flask_loginの機能で以下の文を実行することでセッションを付与することができる。 login_user(User(request.form['username']))

アプリケーションがログインセッションを受け取ったとき、セッションに含まれるユーザーIDからユーザ情報を取得してチェックすることをユーザローダという。

#2025.05.05 アプリケーションをサーバレスにデプロイしていく。 セッション情報をDynamoDBに保存するためにflask-sessionstoreをインストールした。 (インストールを仮想環境を有効にせずにしてしまったが大丈夫かな?) ->インストールし直した。インストールを実行するディレクトリも重要と思われる。

改変を加えたら、flask cliで"flask init-db"が使えなくなっている。 ->使えなかったポイント 1.仮想環境が違っていた。applicationディレクトリのPipfileが正であったが、上位ディレクトリにも間違えてPipenvを初期化していた。そちらで仮想環境を有効にしていたから。 2.インポートしたモジュールのクラスを勝手に変えてしまったから。(良い勉強になりました。)

"flask init-db"を実行しSessionテーブルを作成した。

アプリ起動確認したところ、RuntimeErrが発生。secret_keyが設定されていないという内容であった。

#2025.05.06 Runtimeエラーの原因はconfigファイルのSESSION_DYNAMODB_TABLEに設定していた文字列が間違っていた。 serverless_blog_sessionsの最後のsが抜けていた。この対処のあとはクライアントエラーに変わった。 色々対処をしていったが、sessionstoreは最終リリースが2017年でありメンテナンスされていないようであったので、flask-sessionに変更した。 変更した直後からログイン画面すら表示されなかったのが表示されるようになった。 ログイン実行時はまだクライアントエラーが発生したが、セッションテーブル再作成で正常に動作するようになった。 セッションテーブルを作り直そうとしたがflask-sessionが自動でテーブルを作成するようである。現在のような__init__.pyにflask-CLIを記述する構成にしているとSession(app)で自動的に作成されてしまうので注意が必要。

#2025.05.07 サーバレスでデプロイするための準備。AWSユーザーを新たに作成した。 新たに作成したAWSユーザーのアクセスキー等の値を環境変数として.bashrcに設定を記述。 config.pyを編集。開発環境と本番環境でそぞれ環境変数を読み込む設定とした。 configの設定をしたところflask-loginモジュールが見つからないというエラーが発生した。 ->単にクラスの継承をしていなかっただけであった。

#2025.05.08 ログイン時にscanエラーが発生。ユーザー名はjhonなのにパスワードはpuroduction用のパスを要求されている。 環境変数がproductionとなっているからと予想する。 予想は当たり。全て正常に動作するようにした。

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

1 watching

Forks

Releases

Packages

Used by

Contributors

Languages