Zenn
🐳

2024年に調べたり構築した開発環境について

2024/12/31に公開
Docker
Git
Linux
VS Code
tech

はじめに

2024年に調べたり構築した開発環境について、振り返っておこうと思います。基本的に Linux をメインに Web アプリの開発環境を構築することが多いです。

今どきの Web アプリの開発環境というと、VS Code + Docker + Git が必須となっているので、これらをベースとして環境構築をしています。2024年は、これらを使った開発環境の構築をしていました。また、構築にあたって、いろいろと調べていました。

Visual Studio Code

Visual Studio Code は、Linux、Windows、macOS に対応していて、Intel系 CPU だけでなく ARM 系 CPU にも対応している OSS ベースの高機能エディタということで、重宝しています。VS Code や、vscode と省略されることがあります。

本体だけでも十分便利なのですが、拡張機能も充実しているのが、ありがたいです。プロファイル機能を使って、使用する拡張機能の切り替えをある程度するようにしています。

拡張機能としては下記は必ずインストールしています。拡張機能名: 拡張機能 ID で表記してあります。

特に、Remote Development には下記が含まれているので、重宝しています。

Docker

基本は Docker Engine を Linux マシンへインストールして使っています。一応、Docker Desktop も使えるようにはしていますが、こちらは個人利用をするときに使うだけなので、あまり使っていません。

Docker Desktop が提供する GUI も便利ですが、ほとんどの部分については、VS Code + Docker 拡張機能で対応できることなので、基本的に VS Code を使うようにしています。とはいえ、Docker Desktop の拡張機能も便利なものがあります。Docker Desktop を使う場合は、次のものをインストールしています。

  • Resource usage
  • Volumes Backup & Share
  • Disk Usage
  • Logs Explorer
  • Portainer

開発コンテナー dvc

VS Code の Dev Containers 拡張機能を使うと、開発コンテナーを使うことができるようになります。単純に VS Code をアタッチするという手軽な使い方から、devcontainer.json を用意して本格的に使うということもしています。

さらに、開発コンテナーを自分でビルドしてカスタムイメージも用意して使っています。Docker Hub と GitHub に自分でカスタマイズしたものを公開しています。

いずれも https://github.com/devcontainers/images/tree/main/src/typescript-node で公開されている typescript-node 開発コンテナーをベースとしています。

最初、Node.js 環境と docker-outside-of-docker が使える開発コンテナー環境を自作していたのですが、mcr.microsoft.com/devcontainers/typescript-node をベースとして feature を組み合わせた Docker イメージを作れば手軽に環境構築ができるので、そちらの方法へ変えました。

Python、Go、Ruby などを使った Web アプリ開発もあるので、それに合わせてイメージを用意してあります。Web アプリの開発なので、Web ブラウザも使えるように desktop-lite の feature も組み合わせてあります。

hiro345g/dvc の GitHub リポジトリでは、次のプログラミング言語に対応する開発コンテナー（Dev Container）用のイメージをビルドする方法を提供しています。

イメージ名:タグ os node vnc mise go jdk php python ruby
dvc:base-202411 debian 12 22 - - - - - - -
dvc:novnc-202411 debian 12 22 1.12 - - - - - -
dvc:novnc-mise-202411 debian 12 22 1.12 i - - - - -
dvc:novnc-go-202411 debian 12 22 1.12 - 1.23 - - - -
dvc:novnc-jdk-202411 debian 12 22 1.12 - - 17,21,23 - - -
dvc:novnc-php-202411 debian 12 22 1.12 i - - 8.2 - -
dvc:novnc-python-202411 debian 12 22 1.12 - - - - 3.12 -
dvc:novnc-ruby-202411 debian 12 22 1.12 - - - - - 3.1
dvc:novnc-gnr-202411 debian 12 22 1.12 - 1.23 - - - 3.1
dvc:novnc-gnpr-202411 debian 12 22 1.12 - 1.23 - - 3.12 3.1

表内の debian 12、vnc、mise については次のとおりです。

  • debian 12 のコードネームは bookworm
  • vnc は TightVNC
  • mise は jdx/mise の略、i でインストール済みでバージョンは 2024.11.1

Git

Git 関連については VS Code から使うことが多いので、下記拡張機能をインストールしています。

Git 向けのシステムについては、関連するソフトウェアも含めて、いろいろなものを動かしてみたので、それらをアドベントカレンダーで紹介しています。この後に紹介するものについて、具体的に試用してみたいものがあったら、次の記事が参考になるかもしれません。

GitLab

Git リモートリポジトリについては、専用の Linux KVM 仮想マシンを用意して、GitLab Community Edition を動かしています。

GitLab は、それなりに高いリソースを要求するので、手軽に Git リモートリポジトリを用意したい場合には適していません。ある程度 Git について理解していて、十分な性能を持つマシンがあって、Git システムを構築したいと考えている人向けになります。高性能でビジネスユースにも対応できるため、本格的に自宅で開発環境を構築したい人は興味を持つはずです。

ちなみに Linux KVM（Kernel-based Virtual Machine）というのは、Linux カーネルに組み込まれているオープンソースの仮想化技術です。Linux をハイパーバイザーとして動作させ、複数の独立した仮想マシンを稼働させることができます。https://git.kernel.org/pub/scm/virt/kvm/kvm.git で開発されています。Docker Desktop for Linux でも、Linux KVM が必要で、これを使って Docker ホストを動作させるための仮想マシンが用意されます。

2024年は、Docker で CI/CD 用の GitLab Runner を動かしてみています。まだ、普段使っている GitLab とは接続させていなくて、同じく Docker で動かしている GitLab と接続させています。GitLab は仕事で使うこともあるので、Docker によるローカル動作確認環境を用意してあるというものになります。

軽量の Git システム

2024年は GitLab よりも入門しやすい軽量の Git システムを探していて、現時点では次のどれかが良いと考えています。

CI/CD 用のタスクランナーを Git システムと切り離して用意しておく場合は、次のものが良いと考えています。

CI/CD 用のタスクランナーについて、これらのものにするメリットは、採用している Git システムに依存しない構成が可能となる点です。いろいろな Git システムと連携ができるので、プロジェクトによって使っている Git システムが違う場合でも、同じタスクランナーで対応することができます。

このあたりは、CI/CD を専業的に担当する部門があるのか、開発者が CI/CD 部分も担当する分担となるのか、といった体制によっても変わってくるはずです。会社によっては、CI/CD はクラウドサービスを利用するという方針の場合もあるでしょう。

ただ、有料のサービスを利用する場合はコストとの兼ね合いが出てくるので、事業がスケールするときに内製化したいとなる場合もあります。CI/CD を実行する環境は一般的ニーズのものはクラウドサービスの方が安く済むことが多いですが、特殊なニーズがある場合は内製の CI/CD マシンを用意した方が安く済む場合があります。

そういったときに選択肢として、こういったものがあることは知っておいたほうが良いはずです。

hiro345g/gblan

2024年には、ほとんどさわれなかったのですが、2023年には、大学生の知り合いのために、インフラ初心者でも簡単に使えるセルフホスト Git システムを環境構築できる次のものを作成しました。

これは、Docker を使って「Git システムも含めた Web アプリ用の開発環境を1台のマシンで構築できる」というものです。

内部的には、CoreDNS, NGINX, GitBucket, PostgreSQL, Adminer, OpenSSH Server を LAN 環境で使えるようになっています。

DNS も含めてあることからわかるように、FQDN の HTTPS 対応 Web アプリを実行する環境を Docker ネットワーク内に閉じて用意することができます。

すでに紹介した hiro345g/dvc と組み合わせることも簡単にでき、Web アプリの開発用の環境構築に使えます。なお、Web アプリ開発ができるエンジニアを目指しているなら、ここで使われている Docker コンテナについて、一通り説明ができるくらいの知識が必要だと考えています。

プログラミング言語バージョン管理

プログラミング言語バージョン管理については、VS Code + Docker の開発コンテナーを使うことで解決することが多いのですが、ネイティブ環境でもプログラミング言語のバージョン切り替えがしたいときもあります。

Ubuntu を使う場合は、apt でインストールできるシステムのものを基本的に使いつつ、他のバージョンを使う必要があるときに、プログラミング言語バージョン管理用ソフトウェアで管理しているものを使うようにしています。

プログラミング言語バージョン管理用ソフトウェアとしては、Node.js なら nodenv、Python なら pyenv、Ruby なら rbenv などのように、プログラミング言語単位でいろいろあります。これらを個別に使うと大変なので、mise を使って管理しています。以前は、anyenv や asdf-vm (asdf コマンド) を使っていたので、それらを使っているマシンもあります。

Java ランタイムを使うプログラミング言語系については SDKMAN! を使用しています。

mise、SDKMAN! については、hiro345g/dvc でも採用していて、基本的に開発コンテナーには1つのプログラミング言語バージョンを入れるようにしているのですが、同じ開発コンテナーで他のプログラミング言語バージョンが必要となったときに、これらを使ってインストールして使えるようにしています。

Web アプリの開発では、複数のプログラミング言語を組み合わせて使うということはよくありますし、便利なツールを使うために python、ruby、go といったコマンドが必要となることもあります。そのため、筆者は開発コンテナーにも組み込むようにしています。

Bash のプロンプト

Bash のプロンプトについて、Docker や Git をよく使うようになってから、プロンプトに表示しておきたい項目が多いので、b-ryan/powerline-shell などを使っています。

メインマシンでは、b-ryan/powerline-shell を使っていますが、Windows や開発コンテナーでは Oh My Posh ベースのものを使っています。コンテナーでは必要に応じて starship/starship を使っています。

starship/starship は軽量で Nerd フォントがなくても、それなりの表示ができるテーマがあるので、VS Code をアタッチして開発コンテナーを軽く使う場合など、簡易的に使いたいときに便利です。これを使ったコンテナーの利用方法は下記で公開しています。

なお、Powerline 系のプロンプトとテーマについて、使用するマシンによって変えることで、勘違いによる操作ミスが発生しにくくなります。プロンプト用のソフトウェアとテーマを変えておきたいものは次のものになります。5パターンぐらい用意しておくと良いはずです。

  • サーバーマシン
  • デスクトップマシン
  • ノートパソコン
  • 開発コンテナー
  • Docker コンテナー

フォント

Powerline 系のプロンプトを使う場合は Nerd 対応フォントが基本的に必要です。また、プログラミング時には I と l の区別がつきやすいフォントを使いたいところです。ということで、フォントについて気にしています。

Nerd 対応フォント

日本語に対応しているフォントでは HackGen、Cica など日本語フォントと英語フォントの両方をまとめてひとつのセットにして見やすくする調整をしたフォントがあります。そういったフォントについて、個人的に選択肢としているものを一覧にしてみました。

他にも、次の URL で公開されている Nerd 対応フォントを使うこともあります。

このサイトのダウンロードページを確認すると、次のフォントをベースとする Nerd 対応フォントもあります。

Noto は CJK のものが Ubuntu Desktop の日本語環境では標準でインストールされるので知っている人も多いでしょう。それと合わせておきたい時は、Nerd 対応フォントも Noto ベースのものにすると良いはずです。

Meslo のものは、Oh My Posh の公式サイトで紹介されているものなので、世界的には人気があるのでしょう。Nerd 対応のフォントは 3.3.0 のものなら Nerdfonts のダウンロードページ からダウンロードできます。

プログラミング用フォント

フォントについては、優先度をつけて複数指定ができるようになっているアプリも多いので、デスクトップ環境だと複数インストールすることが多いはずです。プログラミング用途で使いやすいフォントとしては、次のものがあり、これらも組み合わせて環境を用意することを検討しても良いでしょう。

Linux でよく使うフォント

Linux では、IPA フォントなどがよく使われています。IPA フォントは、IPA (情報処理推進機構) が開発したオープンソースの日本語フォントで、高品質かつ無料で利用できます。よく聞くものを一覧にしておきます。

Docker を使っていて日本語フォントが必要となったときなどに、こういったフォントの名前を知っておくと役に立ちます。

ちなみに、Ubuntu のパッケージだと下記があります。東風フォント（kochi）やさざなみフォント（sazanami）は開発プロジェクトのページがメンテナンスされていないようなので、最近の Ubuntu だと使えないかもしれません。

  • fonts-noto-cjk
  • fonts-mplus
  • fonts-ipafont-gothic, fonts-ipafont-mincho
  • fonts-ipaexfont-gothic, fonts-ipaexfont-mincho
  • fonts-vlgothic
  • ttf-kochi-gothic, ttf-kochi-mincho
  • ttf-sazanami-gothic, ttf-sazanami-mincho

Linux GUI

Linux GUI については、主に Ubuntu Desktop 22.04 を使っています。日本語版 Remix が便利なので、次の URL のサイトからダウンロードしたものを使っています。

Ubuntu Desktop 24.04 は日本語版 Remix がないので本家からダウンロードしたものを使う必要があります。

MATE も良さそうなので使ってみたことがあるのですが、気がついたら Ubuntu Desktop の方に戻っていました。

あと、基本的に開発コンテナーの desktop-lite フィーチャーを使っているのですが、これに採用されている Window マネージャーは fluxbox/fluxbox です。

これは今は開発が止まっていて、更新されていないので、どこかで別の Window マネージャーに置き換わるのだろうと考えています。

Wayland 対応の Window マネージャーには次のものがあります。これらのどれかになるのか、別のものになるのか、どうなりますかね。

ちなみに desktop-lite フィーチャーを使わないで Docker コンテナーで Linux GUI を使いたい場合は、linuxserver/docker-webtop があります。

このあたりは、Docker や WSL で GUI アプリを動かせるなら動かしたいと考えて調べていました。あとは、PDF の自動生成や Selenium 系のテストツールを動かすのにも、知識があった方がよさそうだったというのもあります。

また、2024年は n100 の Windows マシンを使ってみたのですが、これだと WSLg（microsoft/wslg） が使えませんでした。

Intel のチップについては、ドライバーが対応する一覧が Intel GPU ドライバー にあるのですが、AMD については AMD GPU ドライバー を見てもよくわかりません。

D3D12 サポートに対応していれば良いようで、次のものはサポートされているという記事を見かけましたが、具体的なサポートチップの情報が掲載されている資料が見当たらないです。

  • AMD Radeon RX 5000シリーズ以上
  • AMD Ryzen 4000シリーズ以上

最近の Intel の CPU はバグがあると話題になっていたので、新しいミニ PC を買うときには、AMD にしようと思っていて調べていたのですが、Intel と AMD とどちらにするか悩むことになりそうです。どちらの CPU にするにしても、WSLg 対応しているチップにしたいところです。

設計関連ツール

設計時によく使っているツール。

Markdown

ドキュメントは基本的に Markdown で記述するようにしています。図については Power Point 互換のプレゼンテーションツールで編集・参照できるものを使っていますが、mermaid なども採用しつつあります。

OpenAPI

REST ベースの API サーバーや、それを使うアプリについては、基本的に OpenAPI を使うのが楽だろうと考えています。OpenAPI については、OpenAPI Initiative をご覧ください。

OpenAPI の仕様を作成するにあたっては、サーバーサイドで生成するのが良いと考えています。これは、仕様からサーバー用コードを生成するというのが、あまり現実的ではないからです。これは、仕様変更時に特に感じることです。

仕様からサーバー用コードを生成する方式だと、生成したコードと既存のコードのマージ作業がそれなりに面倒なことになり、既存コードに影響する部分を手作業で対応する際の手間が多くなります。

インタフェースと実装を完全に分けて生成できるなら、仕様からサーバーのインタフェース用のコードだけを生成して、その変更により問題が起きた部分を直していくとすれば良いのですが、そういった対応ができるジェネレーターというのはみかけないので、なかなか難しいところがあります。

逆にサーバーのコードから、仕様を生成するようにしておくと、仕様変更時も、サーバーのコード上で変更してから仕様生成をすれば済みます。

一方、クライアント側については、仕様変更後に生成した OpenAPI の仕様からクライアント用のコードを生成して利用するということで良いと考えています。クライアント側は API を利用する側なので、利用するライブラリのアップデートに対応することはいずれ必要となります。この方式の場合、必要となる作業が増えるということもなく、ツールで自動生成できるメリットを享受することができます。

ということで、こういった作業をするのに適したツールがあるか探しながら使っています。

DB 用ツール

DB 用のドキュメントツールとしては、SchemaSpy が便利です。DB のテーブル情報から、ドキュメントを生成してくれます。

ここで、OpenAPI では、サーバーサイドのコードから仕様を生成するのが良いという話をしました。DB についても似たような話があります。

  • a）DB のテーブル情報から DB アクセス用コード生成
  • b）エンティティ用コードからテーブル作成・更新

サーバーサイドのアプリでは、ORM を使うことが多いのですが、大体の ORM は a も b も対応していることが多いです。

こちらも、変更時のコード変更を考えると b の方式が良さそうな気がするのですが、利用する DB に合わせてエンティティ用のコードを調整するというのはなかなか面倒だったりします。

RDB を使う際に、テーブルの正規化をする、テーブル間の関連について制約をつける、といった作業はエンティティ用コードを設計するときの話というよりは、データベース設計の話になります。

サーバーサイドのアプリでは、できるだけプログラムから扱いやすいデータ構造のエンティティとしておきたいのですが、使用するデータベースの機能や制限に合わせて、抽出や永続も考慮したデータ構造にする必要が出てきます。

そういったことを考えると、データベースを利用する場合は、DB のテーブル設計を決定してから、エンティティ用コードを作成するという流れになります。

サーバーサイドのアプリのコードを変更する場合も、DB に保存するデータの構造について変更が必要なのか検討するところから始めるはずです。

となると、a の「DB のテーブル情報から DB アクセス用コード生成」という方式の方が良さそうな印象です。この場合は、DB と DB 用コードの作成・更新は次のような手順となります。

  1. データ定義
  2. テーブル作成・変更
  3. テーブル情報から DB アクセス用コード生成・変更

ということで、こういった作業をするのに適したツールを、使用する DB やフレームワークで探しながら使っています。

プログラミング言語

構築した開発環境で使ってみているプログラミング言語やフレームワークなど。

TypeScript

Web ブラウザで表示する画面を作る場合は TypeScript でコードを書くのが良いと考えています。型がない開発はやはりきつい。

フロントエンド向けのフレームワークは次のものが有名で、チェックしています。

サーバーサイド向けのフレームワークは次のものをチェックしています。

OpenAPI の spec.json からクライアント用コードを生成するには次のツールがあります。

DB アクセスまわりは、次のものがあります。

Java

Java 関連では、Java Runtime、Java SDK についての知識が必要なのと、Web アプリだと Jakarta EE についての知識が必要です。最近、きちんと調べていなかったので、改めて確認しました。これらについては記事にしてあります。

IDE については、次の記事にしてあります。

VS Code での Java 開発環境についても、それなりに調べたのですが、記事公開まではしていません。選択肢が多く、利用するツールによっても変わってくるので、単純に「こうしておけば良い」という感じではなくなっている印象を持ちました。

VS Code での Java 開発については、まだ快適というところまではいってなくて、Java 専用の IDE の方が高機能で使いやすい印象があります。ただし、開発コンテナーについては VS Code からの利用がしやすいです。

となると、VS Code でも他の Java 専用 IDE でも開発ができる設定でプロジェクトを用意する必要が出てきます。このあたりが、それなりに調整が大変になるところだと感じています。

「Write once, run anywhere」はやはり難しい...

Python

シェルスクリプトだと対応しにくいツールを用意するときは Python が便利だと考えていて、たまに使っています。

ライブラリの管理については、基本的に pip を使っていますが、そろそろ poetry を使った方が良いだろうかと思って試用してみたときの記事を公開してあります。

Web アプリ用のフレームワークについては、API の開発なら FastAPI、手軽な Web GUI アプリなら Flask、高機能な Web GUI アプリなら Django を採用という方針でいます。

FastAPI は OpenAPI の spec.json 生成にも対応しているので使いやすいです。

DB アクセスまわりは、次のものになります。

Python だと、次のフレームワークもチェックしています。

Streamlit は Python で Web UI を持つアプリを手軽に作れることから人気があります。Flet は Flutter ベースの Android/iOS アプリが開発できます。動的な Web サイト用 アプリを開発することもできます。ただし、この場合は内部的に FastAPI を使った実装になるため、Android アプリ や iOS アプリとしてのパッケージ化はできません。

Go

開発用ツールを手軽に用意するには Go を使うのが良いという話があって、それの賛成派です。Docker Engine も Go で実装されていて、実績は十分にあります。

マルチプラットフォーム対応の実行ファイルが手軽に用意できるのも魅力です。たとえば、ラズパイ用のツールを Intel/AMD マシンで開発してクロスコンパイルするのが、本当に手軽にできて、ありがたいことです。

サーバーサイド、OpenAPI 対応、DB アクセスについて、次のものがあります。

PHP

PHP は他のプログラミング言語での Web フレームワークが普及してきたことから、筆者は以前ほど「手軽に Web アプリを開発するのに便利」だと感じなくなってきています。言語仕様も PHP7, PHP8 で強化された分、覚えないといけないことが増えたのも影響しています。

パッケージ管理は composer がない頃に比べると、しやすくなりました。

Web フレームワークについて、こちらも個人で開発するときは軽量なものがいいと考えてチェックしていて、Slim や CakePHP が良さそうだと考えています。

高機能・高性能の要求がされる場合は Java や Go を使うことにしてしまうので、筆者が Laravel を採用することはあまりなさそうです。PHP エンジニアが多いプロジェクトや PHP が得意な人だと Laravel を使うことになるのだろうという印象です。

CMS は WordPress が使えれば良いという考えです。プラグインを使えばサイトジェネレータとしても活用できるので、動的サイトだけでなく、静的サイト用にも使えます。

ただし、記事更新のために WordPress を起動しないといけないというのは負担となるので、Markdown などで記述できるサイトジェネレーターへ移行したいという気持ちもあります。

Rails

Ruby で Web アプリといったら Rails なので、チュートリアルの最初の方を動かせる開発コンテナを用意して、さわってみています。

GitLab や Redmine は Rails を採用していて、世の中では Rails を使ったサービスも数多くあります。そういったことから、Rails についてもさらに理解を深めたほうが良いのだろうという印象を持っています。

スタティックサイトジェネレーターと CSS フレームワーク

ランディングページやポートフォリオページを作る場合は、スタティックサイトジェネレーターと CSS フレームワークを何にするかが重要になってきます。

スタティックサイトジェネレーターとしては、Jamstack のページが参考になります。Hugo や Jekyll を検討してみたことがありますが、具体的にページを作ったことはありません。

個人で作成する Web サイトというものは下火になっている印象を持っていて、個人的には、使ってみようというモチベーションがあがってきていません。とはいえ、綺麗なポートフォリオページは持っていたほうが良いとも考えていて、検討を続けているところです。

CSS フレームワークは次のものをチェックしてます。

Bootstrap ベースのテーマとしては日本語フォント対応しているものがきれいなのだろうと思って調べてみたことがあります。

おわりに

後半、開発環境構築から話がずれている感じもありますが、構築した開発環境がターゲットとしているプログラミング言語やフレームワークの説明にはなったのではないかと思います。

プログラミング言語については下記も使えるようになりたいという気持ちは持っていますが、なかなかきちんと使うというところまでにはいかないです。

2024年は開発コンテナーとセルフホスト Git システムを中心に色々と調べたり、環境構築をしてきました。2025年は構築した環境を使って、気になるプログラミング言語やフレームワークを使ってみていきたいと考えています。

最後に宣伝です。環境構築にあたってはバックアップが大事です。バックアップ時に使用する GParted について書籍を出してますので、よろしかったら購入をお願いします。

Discussion