Python on @johtaniの日記 3rd

VS CodeとDev Container（docker-compose.yml対応）

Fri, 21 Jul 2023 10:13:30 +0900

前回の記事で、VS Code＋Dev Containerを導入しました。残課題として「マルチコンテナ化」があるという話もしました。今回はDev Containerのdocker-compose.yml対応をした話をメモとして残しておきます。実際、VS Code + Dev Containerに移行した後に、Esを起動してアプリからつなげるというのがうまくいかないというのがあったので対応がんばりました。。。

Dev Containerのdocker compose設定

この記事ではすでにdocker-compose.ymlが存在している状態の話をします。変更する前は、devcontainer.jsonでベースのコンテナイメージの指定、マウントの設定などを行っていましたが、docker-compose.ymlにいくつかを移動しないといけません。対応した時の作業の流れは以下のような感じです。

ワークスペース用のDockerfileの作成
docker-compose.ymlにワークスペース用のサービスを追加
devcontainer.jsonをdokcer-compose.ymlを利用する形に書き換え
アプリでの接続文字列をlocalhostからdocker-compose.ymlのサービス名に変更

参考：対応した時のコミットです。差分などはこちらをごらんください。

devcontainerのリポジトリにPython+PostgreSQLのサンプルが公開されており、こちらを参考にしながら作業をしました。

1. Dockerfileの作成

docker-compose.ymlだけでも完結するのかもしれないですが、いろいろやりたいことも出てくるかもしれないので別のファイルに切り出しました。といっても、コンテナのイメージはdevcontainer.jsonに記述していたものを使っています。

ARG VARIANT=3.11-bookworm
FROM mcr.microsoft.com/devcontainers/python:${VARIANT}

ENV PYTHONUNBUFFERED 1
ENV TZ Asia/Tokyo

TZはdevcontainer.jsonで指定していたものを、こちらに移行した形になります。 PYTHONUNBUFFEREDは参考にしたDockerfileの記載です。標準出力・エラーをバッファリングしない指定になっています。

2. dokcer-compose.ymlにサービス追加

backendという名前のサービスをdevcontainer（VS Code）から接続するコンテナのサービス名にしています。

services:
  backend:
    build:
      context: .
      dockerfile: .devcontainer/Dockerfile
    init: true
    environment:
      - TZ=Asia/Tokyo
    command: sleep infinity
    volumes:
      - .:/workspace/search-research:cached
      - venv-search-research-backend:/workspace/search-research/.venv
...
volumes:
  venv-search-research-backend:

1.で作成したDockerfileを利用します。docker-compose.ymlファイル自体は、プロジェクトのルートディレクトリに配置していますが、Dockerfileは.devcontainerディレクトリに入れたため、contextとdockerfileはこのような指定になっています。

initは、devcontainer.jsonで指定していた"runArgs": ["--init"],の設定になります。

commandの部分は、コンテナが起動したままにしておくための設定です。

volumesでは2つのボリュームに関しての指定があります。 1つ目の/workspace...は、VS Codeがコンテナにプロジェクトをマウントする場所の指定です。 devcontainer.jsonだけを利用していた場合は意識していませんでしたが、/workspace/プロジェクト名というディレクトリにプロジェクトがマウントされていました。 docker-compose.ymlを利用する場合は、明示的に指定が必要です。 2つ目のvenv-...は.venvのディレクトリをコンテナの中だけのものにする設定を移植したものになります。前回の記事ではコンテナIDをボリューム名に含めていましたが、こちらのほうがわかりやすいかと思い、プロジェクトの名前とサービス名をつけるようにしてみました。 Dev Containerで起動した場合はsearch-research_venv-search-research-backendという名前がついています（最初の部分はDev Containerがつけてるのかな？）

3. dovcontainer.jsonの変更

devcountainer.jsonから呼び出すものの準備ができたので、devcontainer.jsonを書き換えます。公式のドキュメントとしてDocker Compose向けのプロパティが紹介されています。変更したものは次のような形です。

{
  "name": "search-research",
  "dockerComposeFile": "../docker-compose.yml",
  "service": "backend",
  "workspaceFolder": "/workspace/search-research",
  "postCreateCommand": "/bin/sh ./.devcontainer/postCreateCommand.sh",
  "customizations": {
...

dockerComposeFile : 利用するdocker-compose.ymlのファイルパス
service：VS Codeが利用するワークスペース用のサービス名
workspaceFoldeer：VS Codeがコンテナに接続したときに開くフォルダのパス

を指定します。これで、VS Codeでこのプロジェクトを開いた時に、Dev Containerがdocker-compose.ymlを使ってコンテナの起動（ビルドとか）を行ってくれます。

4. アプリの接続文字列の書き換え

こちらはおまけです。 PythonのアプリからElasticsearchに接続するときの文字列として、Dev Container化の前は、http://localhost:9200と指定をしていました。 Elasticsearch用のサービス（es）で、ポートフォワードをしていたためです。

アプリ側もコンテナ化したので、Docker Composeが名前の解決をしてくれるので、http://es:9200という接続文字列で接続ができるようになりました。

ということで、ここまでで、VS Codeでプロジェクトを開くと、2つのコンテナ（backendとes）が起動してVS Code上でPythonアプリからEsへの接続ができるようになりました。

追加の変更

参考のプルリクでは、上記まででしたがさらにいくつかの変更をそのあとやっています。

起動するサービスの指定(開発だけするときはEsを起動したくない)
- devcontainer.jsonでrunServicesを使って指定できます（公式ドキュメント）
GPUをコンテナから利用できるように
- devcontainer.jsonでfeaturesのnvidia-cudaを指定し、docker-compose.ymlでnvidiaのドライバーなどを設定することで対応しました。
- nvidiaが公開しているcuda対応のコンテナイメージでもよかったのですが、こちらのほうが楽そうだったという理由です。featuresとコンテナのビルド、postCreateCommandの順序などはもうちょっと勉強しないといけない気がしています。

これらの対応はこちらのコミットで対応しています。

GPUの対応は、私個人の環境はこれでいいのですが、複数の人がこのリポジトリを使う場合はどうやって切り替えたりするんだろう？という疑問が残っています。。。今回はrinna/japanese-clipのモデルを使って、テキストからベクトルを生成する部分の処理のためにGPUを使いたいというモチベーションがあり、コンテナでもGPUを使えるようにしています（CPUだと時間がすごくかかる。。。）。

サービス起動の新たな問題点

runServicesで起動するサービス名を指定したのはよかったのですが、Elasticsearchのサービスを起動して、データ登録や検索の確認を行おうと思った時に、EsのコンテナをVS Codeだけで起動する方法がまだわかっていません。。。一度コンテナをビルドした後なら、「Remote Explorer」でOther Containerというくくりで表示され、右クリックで起動や停止ができそうなのだけど、新規サービスをdocker-compose.ymlに追加した場合は、自分でターミナルなどでコンテナのビルドをしないといけないかもしれないです。もうちょっと調べてみないとなぁ。

副次的な効果

Docker Compose対応をしたことで、前回の記事での疑問点のうち、「コンテナ名」「VolumeのID」については懸念点がなくなりました。

「コンテナ名」は、docker-compose.ymlのサービス名がコンテナ起動時に名前として利用されるため、Docker Desktopで見た時などの探しにくさはなくなりました。ただ、「イメージ名」については、いまだに2つできています。「-uid」がつかないものの代わりに、search-research-backendというイメージが作られています。ただし、実際に利用されるのは前回の記事に書いたようなvsc-search-research-bf04371c017c8d2f1dd5ad2529841b02e9ea1d1aaa4354c19edf53cef3f0c13b-uidという名前のイメージです。

「VolumeのID」については、docker-compose.ymlのファイルで自分で名前をつけるようにしたので、コンテナのIDが利用されなくなったという次第です。代わりに、プロジェクト名である「search-research」という名前を直接記述しているので、変数などで置き換えたほうがいいのかも？という気がしています。

まとめ

ということで、複数のコンテナを利用するプロジェクトでVS Code+Dev Container対応ができそうだということがわかりました。ついでに、GPU対応もできたのでこれで、やっと他の検索エンジン対応などができる気がしています。（その前にpre-commitを保存時にチェックする形に変更かなぁ）やりたいことからちょっとずつ外れている気もするけれど、新しいことを調べるのは楽しいですね。

VS CodeとDev Containerの導入（まだ途中）

Thu, 13 Jul 2023 22:15:23 +0900

前回の記事で、pre-commitとPyCharmとWindowsの組み合わせで困っていることを書きました。これについて、知り合いとチャットで話をしていて、それほどPyCharmにこだわりもないよなぁということになり、であれば、ISIDのブログ（Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 - ISID テックブログ）を試してみるとすっきりするかもしれないとなり、Dev Container対応をブログを参考に行ってみました。

順を追ってブログで説明されているので、どういう仕組みなのか、どの設定が何を意味しているのか？がとてもよくわかりやすくすんなり対応することができました。

ブログの手順をなぞっているところでいくつか固有の手順や疑問点が出てきたのでブログに書き記しておきます。結果は、コミットしてあるものを見てください。

ブログとは違う手順

まずはISIDのブログとは違う点をいくつか。

.venvはいったん削除

ブログでは新規のプロジェクトを作成していく過程で、コンテナ化した環境を作った後に.venvをDockerコンテナのボリュームにして、最後に仮想環境のPythonを生成していました。私の場合は、すでにホストOS（実際にはWSL2のUbuntuだけど）で.venvのディレクトリを作成してある状態だったので、いったん削除する必要がありました。すでに存在する.venvがbindマウントされてしまっている状態になるため、Dockerのボリュームとの整合性が取れなくなるようです。

この作業を行う前か、途中でDev Containerを停止した状態で、.venvを削除することで問題なくDockerのボリュームに仮想環境のPythonが登録されるようになります。

postCreateCommand.shの呼び出し方

ファイルに実行権限がないと、実行権限エラーが出ました。実行権限を与えるか、次のような記述で動くようになりました。今は、ファイルに実行権限をつけるのではなく、次のような記述にしていますが、何か問題あるかな？

 "postCreateCommand": "/bin/sh ./.devcontainer/postCreateCommand.sh",

実際に動作しているログを見ると

/bin/sh -c /bin/sh ./.devcontainer/postCreateCommand.sh

となっているので、少し気持ち悪いのだけれども。。。

postCreateCommand.shの追加処理

今回Dev Containerを適用したプロジェクトでは、sentencepieceを利用します。この、sentencepieceをpoetryがインストールするタイミングで、cmakeを要求してきました。今回利用しているDocker Imageにはcmakeは含まれていないため、以下の処理を追加しています。

sudo apt update
sudo apt-get install cmake -y

また、rinna/japanese-clipも利用しているのですが、こちらは、poetryで追加してインストールでは依存するパッケージがインストールされないため、pipコマンドを利用するようにしています。

pip install git+https://github.com/rinnakk/japanese-clip.git

コンテナイメージを作った後にやりたいことを、自由にスクリプトで書けるのは便利ですね。

pre-commitのスクリプトの再生成

こちらも、既存の環境が残っているとPythonへのパスの違いの問題が出たので、作り直しました。 .git/hooks/pre-commitのファイルを削除し、pre-commit installをやったものをリポジトリにコミットしてあります。

疑問点

作業をしていて疑問点もいくつか出てきたのでメモを残しておきます。ちなみに、これらの疑問について実際に調べるまでには至っていません。時間を見て解決できればなぁと（できるのか？）。

Imageが2つ

Dev Containerの設定を書いた後に、コンテナをビルドすると、Docker DesktopのImagesにイメージが出来上がります。この時、イメージが2つできあがっています（なぜ？）。

REPOSITORY                                                                                          TAG       IMAGE ID       CREATED      SIZE
vsc-search-research-bf04371c017c8d2f1dd5ad2529841b02e9ea1d1aaa4354c19edf53cef3f0c13b-features-uid   latest    25c7e23416ec   3 days ago   1.69GB
vsc-search-research-bf04371c017c8d2f1dd5ad2529841b02e9ea1d1aaa4354c19edf53cef3f0c13b-features       latest    fcf9eaeb2187   3 days ago   1.69GB

こんな感じで、最後に-uidがついているかいないかの違いです。実際にコンテナ起動時に利用されるのは-uidがついているものになります。なぜ2つになっているのか、1つにする設定などがあるのか？といったところが気になるところです。

Containerの名前

devcontainer.jsonの設定を書き換えて、コンテナをリビルドすると起動したコンテナの名前が自動で割り振られているようです。今は、fervent_hopperとなっています。ランダムにつけられているようなのですが、名前を付ける方法はないのかなぁ？と。

devcontainer.jsonにはnameというプロパティもあるのですが、この値がどこで使われているのかはよくわかっていません。 Remote Explorerでコンテナの一覧が見えますが、ここでは、リポジトリ名が利用されているようです。

VolumeのIDはどこから？

devcontainer.jsonで次のような記述で、.venvのディレクトリようにDockerにボリュームを作っています。

  "mounts": [
    "source=venv-${devcontainerId},target=${containerWorkspaceFolder}/.venv,type=volume"
  ],

実際にコンテナでマウントされている情報を見ると

/workspaces/search-research/.venv
/var/lib/docker/volumes/venv-04emir9hi2caivtjunfe3l17452hkbb3hdut1qflbrn8n924ho5c/_data

となっています。 04emir9hi2caivtjunfe3l17452hkbb3hdut1qflbrn8n924ho5cがdevcontainerIdに相当するのだとは思うのですが、誰がつけたものかなどがまだよくわかっていません。もうちょっとわかりやすいものが使えるほうが嬉しいかも？と思っていたりします。（複数Dev Containerを使い始めると、Docker Desktopで見ると、どのボリュームがどのDev Containerに紐づいているかがぱっと見ではわからない）

.vscodeディレクトリどうしよう？

たぶん、VS Codeを触っている過程で、何かの設定をしてしまったのだとは思うのですが、 .vscode/settings.jsonというファイルができており、次のような内容になっています。

{
  "git.ignoreLimitWarning": true
}

何か意味があるかも？ということで、コミットしてリポジトリに入れたのですが、いらないのかもしれないなぁと。

残作業

とりあえず、VS CodeでPython環境ができて、VS CodeのTerminalでPythonのプログラムが実行できるのはわかった段階です。いくつか、今後調べながらやる必要があるものが残っているのでメモとして残しておきます。

マルチコンテナ化

今回Dev Containerに対応したプロジェクトでは、検索エンジンもDockerのコンテナとして起動して、Pythonのプログラムから接続したいと思っています。となると、docker composeでいろいろと起動するほうがネットワークなどの設定も楽になるのでは？と思っているところです。 Dev Containerのテンプレートがいくつか用意されており、その中に「Python 3 & PostgreSQL (postgres)」というのを見つけたので、このあたりが参考になるのでは？と考えているところです。

pre-commitではなく、保存時にフォーマット

pre-commit＋localのコマンドも動くようにはなったのですが、保存時にフォーマットなどをかける設定もISIDのブログで記載がありました。コミットしようとして、怒られるよりも、保存時に怒られたりするほうがいいかも？という気分になってきています。どこまでが切り替え可能なのか？なども見ながら対応してみようかなと。

もう少し開発してみて改善点を探っていく

とりあえず動いたという段階です。 PyCharmとの違いがあるはずで（たとえば、git周りのGUIの違いとか）、そのあたりでどんな違いがあり、どんなものがあると嬉しいのか？といったものを調べる必要もあるかなと考えています。 TerminalでCtrl+rがうまく使えなかったり(Auto Hot Keyで検索のショートカットに割り当ててしまっているから。。。)などもあるので、この辺も調べていきたいなと。 Windows Terminalを使えたりするのかなぁ？

まとめ

さて、とりあえず、VS CodeでPythonのDev Container環境を作って動くところまでは来ました。 PyCharmを使いこなしていなかったのもあり、それほど違和感なく移行できるような気がしています。調べることはまだまだあるし、プログラム書くつもりが、環境を整える方向に話がずれている気もしますが、まぁ面白いのでよしとするかなぁ。いろいろまだまだ知らないことだらけです。。。

pre-commitとvenvとPyCharm（困ったな？）

Mon, 10 Jul 2023 10:55:48 +0900

最近、趣味（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書き始めました。

きちんとPythonのプログラムをプロジェクトとして書いたことがないので、 Pythonのプロジェクトのディレクトリ構成などを手探りで進めているところです。コードのフォーマットとかもやらないとなぁ？と知り合いのいるSlackでつぶやいたところ、gitのpre-commitフェーズでblackなどのフォーマットやスタイルを修正してくれるツールを実行する方法を教えてもらいました（PRまで送ってもらえたのでありがたい）。

で、pre-commit周りの設定などを変えている段階で遭遇した問題点についてログを残しておこうと重いブログを書いています。残念ながら現時点では解決してないんですけどね。。。

手元の環境

簡単に環境を書いておくとこんな感じです。

Windows上のPyCharmを開発で使用
プロジェクトのディレクトリはWSL2のUbuntu上
Python、gitはUbuntuのものを利用
プロジェクトのルートディレクトリにある.venvにvenvでPythonの仮想環境を作成してある

問題点

遭遇したpre-commitの問題点は次の通りです。

pre-commitの設定でrepo:localでローカルのプロジェクトにインストールしたコマンドを利用するように変更
すると、PyCharmでコミットすると、blackなどのコマンドが見つからない
ターミナルでコミットするときはきちんと動作する

色々調べて試行錯誤した結果、現在はrepo:localでのローカルコマンドを使用する方法はあきらめました。移行は、作業記録みたいなものです。どういう流れでpre-commitを取り込み、ローカルに切り替え、切り戻したかという話です。

pre-commitとpre-commit

最初に少し戸惑ったのは、pre-commitというツールとgitのpre-commitフックです。 gitのpre-commitのフックのために作られたPython製のpre-commitというツールがあります。

このPython製のツールを利用することで、プロジェクトに.pre-commit-config.yamlという設定ファイルを置けば設定に記述されたツールをgit commitのタイミングで実行してくれます。実際には、pre-commitというツールの初期設定のタイミングでpre-commit installというコマンドを実行して .git/hooks/pre-commitというスクリプトが生成されます。 gitコマンドはcommitされた時に（commit前のフェーズ）でこのスクリプトを実行し、そこで.pre-commit-config.yamlが参照されています。

.pre-commit-config.yamlの記述は次のようなものになります（最初にもらったPRより）。

repos:
  - repo: https://github.com/psf/black
    rev: 23.3.0
    hooks:
      - id: black
        args: ["--line-length", "120", "."]
  - repo: https://github.com/pycqa/flake8
    rev: 6.0.0
    hooks:
      - id: flake8
  - repo: https://github.com/pycqa/isort
    rev: 5.12.0
    hooks:
      - id: isort
        args: ["--profile", "black", "--filter-files", "--multi-line", "3"]
  - repo: https://github.com/pre-commit/mirrors-mypy
    rev: v1.4.1
    hooks:
      - id: mypy

実際に、PRを取り込んで動かしてみたところ、blackなどが動いて行末のスーペースの除去や未使用のimportについて指摘をしてくれました。便利だなと思ったのですが、ここで疑問が。

今回は対象とするプロジェクトはpoetryで依存パッケージの管理を行っています。今回、上記を動かすためにpoetryに追加されたものはpre-commitだけでした。「あれ？blackとかはどこにあって、どうやって動いてるんだ？」という疑問が出てきます。コンフィグファイルにはパスなどの記載をせず、それぞれのgithubリポジトリの記載とバージョンがあるからです。

pre-commitが使用するツールのインストール先

調べてみたところ、どうやらホームディレクトリにある.cache/pre-commitにblackなどのコマンドが見つかりました。 pre-commitツールが設定ファイルを基に、必要なコマンドをgithubからダウンロードしてきて実行時に利用しているようです。 pre-commitは便利なのだけど、せっかくPythonのプロジェクトだしそれぞれのツールはpoetryでpyproject.tomlでバージョンや設定を管理したほうがすっきりするのではないか？ということで、少し調べてみました。

同じようなことを考えている方がブログを残していてくれました（Pythonレポジトリ用のpre-commit環境を整える）。設定をpyproject.tomlに移行し、そのあと、ローカルのpetryでblackなどのコマンド類をインストールして利用する設定に書き換えています。先人の肩に乗っかって、手元で同じようにpre-commitの設定ファイルのrepoをlocalに書き換えていき（その時のコミット）、ターミナルでpoetry run pre-commit run -aで動作確認できました。

PyCharmでコミットしたらエラー

ですが、実際に変更した状態でPyCharmからコミットしたら、コマンドが見つかりませんというエラーが出ます。。。 WSL2のターミナルでgit commitした場合は問題ありません。どうして？となりますよね。。。。

.git/hooks/pre-commitはPyCharm、ターミナルのどちらからも実行されています。ですが、PyCharmではblackなどが見つからないというエラーが出ました。

.git/hooks/pre-commitを見てみると、python実行するためのpythonのパスはプロジェクトにある.venv/bin/pythonを指定しています。デバッグのために、このスクリプトにecho $PATHを差し込んで、git commitをPyCharmとターミナルからそれぞれ実行してみたところ、大きな違いがあります。

ターミナルで実行した場合は、<プロジェクトのディレクトリ>/.venv/binもPATH環境変数に存在していました。このため、.venv/binにあるblackなどを実行できています。

PyCharmはWindowsから起動しています。プロジェクトのインタプリタとしては、WSL2のUbuntuにある.venv/bin/pythonを指定しているためもあり（？）、出力されたパスは/mnt/c/などのWindowsのパスなども入っていたりしますが、<プロジェクトのディレクトリ>/.venv/binは見つかりません。

ここからはソースコードは読んでいないので憶測ですが、.git/hooks/pre-commitで呼び出されているpre-commitツール（Python製）は、設定ファイルで指定されたコマンド（blackなど）を、コマンドとして今の呼び出されたコンテキストで実行しているのではないかということです。実際、ターミナル上でもsource .venv/bin/activateを実行していない状態だとコマンドが見つからないというエラーが出ました。

対処方法は？

ということで、今考えられる対処方法としては次の通りです。

.git/hooks/pre-commitのスクリプトを修正して、<プロジェクトのディレクトリ>/.venv/binのパスを見えるようにする
PyCharmで何かしらの設定を探す
PyCharmではgit操作しない
repo:localはあきらめて、.pre-commit-config.yamlでblackなどは管理して、pyproject.tomlからは除外する

1.ですが、.git/hooks/pre-commitはprecommit intallを実行すると自動で生成されるスクリプトです。自分の環境で書き換えたとしても他の人が同じ環境を作るときにパッチを当てるなどをしないといけなくなります。

2.はそれらしい設定を見つけることができませんでした。

3.はめんどくさいですよね。。。ターミナルでgitのコメントを日本語で書くためにいくつか他の設定を考えないといけないです。。。

ということで、今回は4.の対処をとりました。やりたいことは、ツールや環境をそろえるのではなく、プロジェクトでやりたいことをやることなので。。。

まとめ

最終的には元に戻ってしまいました（pyproject.tomlに設定周りは移動した）。 Windows環境がちょっとややこしくしてるかもな？というのと、個人のプロジェクトなのでそこまで気にしなくてもいいのでは？というのもありそうです。それにしても、世の中の皆さんはフォーマッターとかどのタイミングで動かしてるんだろう？とかどういう環境構築してるんだろう？とか気になってます。最近だとこういうディレクトリ構造にする、こういうツールを使うと便利などあれば、コメントいただけると嬉しいです。

教えてもらったISIDのブログ（Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 - ISID テックブログ）も参考にさせてもらおうと思ってるところです。Pythonの環境をコンテナに移動したいなぁというのもあるので。ただ、PyCharmだからこのブログの通りには行かないけど（VS Codeに移るのも検討したほうがいいのかなぁ）。