日別アーカイブ: 2024年8月24日

GitHub Copilotの活用を進めてみた

週末、相変わらずAIちゃんと戯れてみて実際に使える物を作るのはどんな感じかなと実施。

出来上がった物はこんな感じ

 

https://github.com/studioes/copilot-WoL-Flask

所要時間は環境設定込みで2~3時間と言う所でしょうか。

検索して情報・方法を得てコードを書くと言う部分が殆どCopilot任せになるので知らない技術を用いる場合には非常に有能に動いてくれます。 ○○について調べておいてって依頼するより遙かに早く結果が帰ってきます。

今回は自宅マシンをWoLするWebアプリケーションが欲しかったのでそれをCopilotとペアで開発しました。

最初のプロンプトは主機能であるWoL部分です。

>MACアドレスにマジックパケットを送信してWakeUpする処理

はい、マジックパケットの詳細は知りませんでしたが、ちょっと知っている情報からプロンプトを組んだら作ってくれました。 わずか数秒で。 普通ならGoogleでWoL magickpacket Pythonとか入れて検索して探して読んで・・・となって数百倍の時間かかるところが数秒です。 こういった所は非常に有能です。

そして追加プロンプト
>FlaskでWebから使える様に
Flaskの基本形が出来て/にGETならMAC入れるフォームが出来て、POSTなら先の物を呼び出す処理が出来上がりました。

ここからは機能を足したり、調整したりですが、ザックリ機能をつける場合はCopilotにお願いすれば入力時間より早く上がってきます。

>SQLAlchemyとsqliteでマシン名とMACアドレスを保存出来るようにして

>マシン名からMACアドレスを取得して保存出来るようにして

>Machineの編集、削除機能を作って

>Machineの一覧を作って、WakeOn、Edit、Deleteへのリンクを付けて

 等の様にしてFlaskルート+処理実体が次々と出来上がりました。

 他方で調整は解釈違いが起きるので人力の方が早いかなという印象。 これは普通にエンジニアがやっていても起きるヤツですね、要件者のイメージがうまく共有出来ないって言うヤツ。 なので、基本部分をCopilotで生成し人間が調整、調整したのをCopilotに学んで貰った上で、以後の調整を補完など支援して貰うって言うのが現状のベストかなと感じました。

ちなみに、README.mdについてもChatで「このプログラムのREADME.mdを作って」とお願いすると、それっぽく概要が出来上がってきて、いまいちだけど必要事項も入っていて、何も無いよりは良い、ちょっと待つだけでこの程度出来るなら十分。 という感じでした。

 現状はVSCodeでやっていますが、PyCharmにもプラグインがある様なのであちらで整備してやりたい感じもします。 個人的にPyCharmの方が最初からPython用にカスタムされててデフォルトの機能も動きが良いのでVSCodeでも出来るけどPyCharmの方がなお良いと言う感覚があります。 また、JetBrains自身もAIアシストがあるようなので、Copilotと比較であちらも試すのもアリかなと(しかし、評価期間がCopilot30日に対して、JetBrainsは7日しか無い)

(16)

カテゴリー: LAMP[Linux, Apache, MySQL, PHP] | コメントをどうぞ

Cloud RunでChrome/Selenium/FastAPIな環境を作る

 新しい勤務先がGoogle Cloudメインなのでそれになれる為に各種リソースをおさわりしています。

 今回は無料枠があるけどあまり利用していなかったCloud Runを活用してサイト監視のシステムを作ってみました。

 Cloud Runは、コンテナを走らせてくれる環境で、普通にDockerファイルを用意してやれば動きます。 今回は自分のサービスのハイレベル監視をこれで動かそうと言う事で、Seleniumによるアクセスを行うコンテナを作りました。

 Dockerfileはこんな感じになりました。
 ベースはUbuntu24,04を使い、アプリは/appに配置することにしました。
 Selenium+Chromeを中で動かすためにaptで結構色々ライブラリやら日本語フォントやら入れています。 Ubuntuミニマムだと数十MBのイメージがで来ますが、これだと1.5GB位(Artifacts Registoryの仮想サイズで600MB+なので無料枠を微妙にはみ出します)
 開発環境はDockerとか諸々のツールが入ってるディレクトリの下にsrcディレクトリを切った状態で作業しているので、コンテナを作る時にはsrc以下をまるっとappにコピーしてます。 requirements.txtだけはsrcより上位にあるので追加コピーしてpipで入れて、コンテナサイズ節約のためにaptのパージとか適当にかけてます。
 CMDで出すところが非常に長いです。 これは、Chrome使う時にdbusうごいてねーよって怒られたので、dbusを立ち上げた後にuvicornをスタートさせてるためです。 sleep 1は動かしてるインスタンスが小さいので安定のために待機させてます。

個人なら普通にローカルで作ってアップしてでも良いですが、やっぱり仕事の勉強がてらなので、ここはCloud Buildで継続デプロイも構成。 GitHubのマスターブランチにプッシュしたら走るトリガを作って、cloudbuild.yamlを準備。

最初のDocker PULLは2回目以降のビルドを高速化するために既存のコンテナを取ってきてキャッシュ利用するためのおまじないです。 このビルドだと初期は5分くらいかかりますが、これやると半分くらいで収まります。

で、DockerをビルドしてArtifacts Registoryにpush。
 ターゲット系がus-west1で纏まってるのは無料枠が大抵このリージョンになるので合わせている都合です。 仕事では普通にasia-northeast1。
 pushしたコンテナを使ってRunをデプロイしてます。
 自分用ケチケチなので1Giメモリ1CPUで暴走課金防止のためにタイムアウトも3mと短め、Max-instace1でMin0なので結構コールドスタートになります。 今回はFastAPI側に認証機構を持たせるのでallow-unauthenticatedを指定してます。 内部から呼び出すだけの場合はこれを外して適当なIAM設定の所からコールするのが良いです。
 で、サービスアカウント指定は、Runを呼び出すんじゃ無くRunが使うサービスアカウントなので、例えばCloud Storageに保存するならストレージ書き込みロール、Cloud Loggingに書き込むなら同様にログ書き込みロールを付けるだけで、Run実行などは不要です。 Google Cloudのサービス特に呼ばないならそれこそ何も権限が無い状態でも動きます、デフォのComputeは権限が凄く付いていて危なっかしいので、必ず権限を削った物を用意します。
 デプロイ後に追加のgcloud sdk使った処理がありますが、こちらはArtifacts Registoryからlatest以外を削除してしまう処理です。 リポジトリ自体にもライフサイクル削除機能がありますが、最低1日1回走るって言う機能なので、テストで頻繁にpushしてると削除されるまでの時間でも結構なサイズが溜まってしまうのでデプロイの最後で消しています。 通常はRegistory側の設定だけでこれは不要ですね。

 これで、src配下に置いたソース入りDockerがCloud Run上で動いてくれるので、あとはSchedulerなりなんなりで叩いて走らせます。

アプリ側は基本形はこんな感じでやってます

複数のAPI機能で唯一のchromedriverを使い回すためにグローバルにdriverを作り、コンテキストマネージャのライフスパンを使ってアプリ起動時にドライバを生成し、終了時に落とすためにwithでドライバ呼んで中はyieldのみという感じに。 ChromeDriverFactory.create_driverは各種オプション指定してChrome webdriverを作ってwebdriverを返してます。

後は各種APIを実装、グローバルに置いてるdriverを使い回していく感じ。

この構成でコールドスタートだと10秒くらいかかりますが、まぁ許容かなと。 Cloud Runは立ち上げからレスポンスを返すまでの課金ですが、インスタンス自体は即座に止まらずにアイドルで一定時間残るので、連続でリクエストを投げていく分にはそれほど問題になりません。 表示テスト、ログインテスト、編集テスト、編集結果反映確認テスト、削除テストと順番に投げていくと初回がコールドスタートで15秒とかかかるけど、その後のは2~3秒で進んでいって、サイトがちゃんと動くねテストが一通り30秒とかで終わります。 Cloud Schedulerも3ジョブまで無料(Githubに一つ取られてるのでウチの空きは2個だったので、テスト一式を起動するジョブを1本設定)なので、ほぼ無料で毎時にサイト動作確認とか出来ます。 ちょっとDockerファイルサイズがはみ出してる都合でArtifacts Registoryの課金が月に数円程度の感じ。

リソースのヘルスステータスはモニタ出来ますが、データ壊れておかしくなってるとか言うケースでは検知出来ないので、Selenium等の実際のUI操作テストは有用なので、程よいコスト感で回せるCloud Run+Schedulerのシステムは良い感じですね。

(107)

カテゴリー: LAMP[Linux, Apache, MySQL, PHP] | コメントをどうぞ