Dev Container on @johtaniの日記 3rd

VS CodeとDev Container(コンテナ名の指定)

Thu, 27 Jul 2023 01:22:49 +0000

いくつかある環境をDev Containerで動くように変えていますが、最初に導入した時に疑問点だった「コンテナ名」について解消したのでメモを残しておきます。

コンテナ名の指定

最初のDev Container導入の記事で、起動したコンテナの名前が自動で付与されて、ランダムに変わるという疑問点を書いていました。

docker-compose.yml対応の記事ではdocker-compose.ymlを利用すると、コンテナ名はファイル内で定義されたサービス名で起動されて見やすくなると気づきました。

やはり、Dev Containerでイメージを指定している場合もわかりやすいコンテナ名がいいなと思ったところで、「runArgs」を思い出しました。 Dev Containerからコンテナを起動するときに渡す引数が書けるじゃないですか。そういえば、むかしdockerコマンドを使う時に名前を指定した記憶があったなと。ということで、Google検索です。「docker command args container name」で検索しましたｗ

--nameというオプションで起動時のコンテナの名前の指定ができます。ということで、このブログを生成するためのdevcontainer.jsonに"runArgs"でコンテナ名を指定してコンテナ起動ができるようになりました（「ブログ記述環境としてのDev Container」という記事のdevcontainer.jsonにrunArgsの行を追加しただけ）。

{
    "name": "Hugo - blog generator",
    "image": "mcr.microsoft.com/devcontainers/javascript-node:16",
	"runArgs": ["--name", "blog_generator"],
    "postCreateCommand": "/bin/sh ./.devcontainer/postCreateCommand.sh",
    ...

ブログ記述環境としてのDev Container

Mon, 24 Jul 2023 09:10:32 +0000

このブログの生成には、Hugoを利用しています。ブログ移行日記（その1）に書いてありますが、当時はbrewでインストールしていました。また、Windowsに移行したタイミングで、WSL2のUbuntuにaptでhugoをインストールして利用していました。 WSL2の環境が壊れなければこのままでもいいのですが、最近Dev Containerを触っていたので、このブログを書く環境（おもにHugo）もDev Containerにできるのでは？と気づきました。

ということで、Hugo＋αの環境をDev Container化したので、そのメモです。

必要なもの

ブログを書いて、記事を構築して、公開するところまでに利用するのは次のようなものです。

git
Hugo
node
atomic-algolia

GitHubのプライベートリポジトリでHugoのプロジェクトを管理しています。また、GitHub Pagesで公開しており、生成したHTMLもgitコマンドを利用してGitHubにpushしています。このため、gitコマンドが必要です。

コンテンツの生成はHugoコマンドを利用します（テーマの適用とかいろいろ）。

あと、Algoliaでブログを検索できるようにしており（ブログ移行日記（その4）参照）、Algoliaへドキュメントのデータをアップロードするために、atomic-algoliaを利用しています。こちらは、nodeのモジュールであるので、nodeの環境も必要です。

ベースにするイメージ

Dev Container Templatesというリポジトリが公開されています。こちらを探すと、元となるdevcontainer.jsonが見つかることがあります。 Hugoのものがあるか探してみましたが、残念ながら見つかったのはJekyllのテンプレートでした。今回は、nodeの環境が必要なのでjavascript-nodeを元に編集していきます。

手元のUbuntuのnodeのバージョンが16だったので、バージョン16のイメージを指定します(devcontainer.jsonは後述)。

Hugoの追加

Hugoのテンプレートはなかったのですが、Dev Container FeaturesにHugoのfeatureが用意されていました。 featuresに1行追加するだけでコンテナにHugoをインストールしてくれる便利ものです。

Markdownの環境

Dev Container Templatesを探索していて見つけたMarkdownのテンプレートも参考にしてみました。 VS CodeのMarkdown向けの拡張機能がいくつかリストアップされていたので、ついでに追加です。 markdown-all-in-oneやmarkdownlintはこれまでも利用していたので、他のものも便利だろうということで。他の物はどんなものかを後で調べてみる予定です。

作った.devcontainerの設定はこちら

ということで、出来上がった設定は以下の通りです。

devcontainer.json

{
    "name": "Hugo - blog generator",
    "image": "mcr.microsoft.com/devcontainers/javascript-node:16",
    "postCreateCommand": "/bin/sh ./.devcontainer/postCreateCommand.sh",
    "features": {
        "ghcr.io/devcontainers/features/hugo:1": {}
    },
    "customizations": {
		"vscode": {
			"extensions": [
				"yzhang.markdown-all-in-one",
				"streetsidesoftware.code-spell-checker",
				"DavidAnson.vscode-markdownlint",
				"shd101wyy.markdown-preview-enhanced",
				"bierner.github-markdown-preview"
			]
		}

    }
}

postCreateCommand.shでは、npm installで、必要なモジュールのインストールをコンテナビルド後に実行できるようにしました。（apt updateはなくてもいいな）

postCreateCommand.sh

#!/bin/sh
# postCreateCommand.sh

echo "START Install"

sudo apt update
sudo chown -R vscode:vscode .

npm install

echo "FINISH Install"

まとめ

ということで、ここ最近Dev Containerについて色々調べていたのでサクッとDev Container化ができました。まぁ、HugoのFeatureが用意されていて、他に大したことをやっていないというのが大きいのですが。このブログは今回構築したDev Containerで生成して公開した記事になります。

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を使いこなしていなかったのもあり、それほど違和感なく移行できるような気がしています。調べることはまだまだあるし、プログラム書くつもりが、環境を整える方向に話がずれている気もしますが、まぁ面白いのでよしとするかなぁ。いろいろまだまだ知らないことだらけです。。。