まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

タグ:linux

最近、VM を扱う機会が多くなりました。何度も色んなパーティショニング要件で Linux をインストールしている中で、これまでちゃんと理解してなかった VG(Volume Group) と LV(Logical Volume) についても理解が深まりました。そのアウトプットの1つとして、ルートディレクトリの容量を無限に増やすことができるような形で Linux VM(VM でなくても OK)を作るための手順等を紹介しようと思い、まずはその前提知識となる VG / LV についてまとめてみます。


【「ルートディレクトリ容量を増やせるようにする」とは?】
Linux に慣れる前に使っていると、最初のうちはあまり深く考えずに VM 等で Linux 環境を用意して使い続けることになり、どこかのタイミングで特定のディレクトリにデータが集まりすぎてディスクが足りなくなってしまう、という経験はないでしょうか?

例えば MySQL データベースとして使っていると、(デフォルト設定だと)そのデータは /var/lib/mysql/ 以下に溜まっていきます。データを多く扱ううちにこのフォルダ以下に大量のファイルが溜まっていくことになります。 また(WordPress のような形も含めて)httpd サーバーとして多くのデータを扱っていると、/var/www/html/ 以下に多くのファイルが溜まっていくことになります。このようにあらかじめ容量に注意すべきディレクトリが分かっている場合は、そのディレクトリに大容量ディスクをマウントして使うとか、その上で LV 化(後述)しておいて後から容量追加できるようにしておく、といった準備が可能です。

問題はそのような大容量が必要なディレクトリ(上述の例だと /var/lib/mysql や /var/www/html )が事前にわからない場合です。最初はそもそも多くのデータを使うつもりもなく作った環境を、後から当初想定していなかった用途でも利用するようになって、あらかじめ容量を拡張できるような準備をせずに使い始めることもあると思っています。しかもこの場合だと利用開始時点では「どのディレクトリに多くのデータが集まるのかもわからない」ので、事前に準備できることがあるとすれば「/(ルートディレクトリ)の容量を後から動的に追加」できるようにしておく必要があります。

特定のサブディレクトリ以下ではなく、ルートディレクトリ自体が拡張可能になっていれば「後からディスクが足りなくなる」ことへの不安はかなり解消されると思っています。


【PV と VG と LV の関係】
以下、"PV", "VG", "LV" という用語を使います。まずはこれらの意味を簡単に紹介します:

PV(Physical Volume): 物理ボリューム
後述する「論理的なボリューム」に対比する意味での「物理的なボリューム」です。論理的なボリュームでは複数のディスクをまとめて1つのディスクであるかのように扱うのに対し、物理的なボリュームでは複数のディスクを(パーティショニングすることはあっても)1つにまとめて扱うのではなく、あくまで1つのディスクは1つとして取り扱う考え方です。厳密には1つの物理ディスクをパーティショニングして1つまたは複数の空間(=ボリューム)として扱います。「論理ボリューム」という考え方をしないのであれば「1つの物理ディスク内の1パーティション=1つの物理ボリューム」です。

VG(Volume Group): ボリュームグループ
PV とは逆に、複数のディスクであっても論理的に1つのディスクとしてみなす、という考え方です。この論理的なディスクをボリュームグループ (Volume Group) と呼びます。

複数の物理的なディスクをまとめて1つの VG を定義します。VG には後からディスクを動的に追加することもでき、そのサイズは追加したぶんだけ増えます。

LV(Logical Volume): 論理ボリューム
Linux のファイルシステムはマウントと呼ばれる仕組みで複数のディスクを1つの空間にマッピングすることができます。この考え方は物理ディスクだけでなく、論理ディスクにも適用できます。

物理ディスク同様に、複数のディスクからなる論理的な1台のディスクをパーティショニングしてマウントすることになります。この論理的なパーティションが論理ボリューム(LV) となり、LV を管理する方法を LVM (Logical Volume Manager) と呼びます。


【2つの物理ディスクを使った場合の比較】
2つの物理ディスク(/dev/sda 容量は 100GB と /dev/sdb 容量は 200GB)を使って Linux マシンを構築するケースを想定し、PV で作る場合と LV で作る場合を比較します。

PV で(というか、LV を使わずに)ルートディスクを作る場合、/dev/sda に1つのパーティション /dev/sda1 を作ってルート(/)にマウントすると仮定すると、100GB のディスク容量を持つファイルシステムが作れます:
2025090501


一方、LV(論理ボリューム)では物理的なサイズやとは関係なく、論理的に定義した空間の容量として考えます。例えば /dev/sda1 を1つの VG とみなし、この VG 全体を1つの LV とみなしてパーティションを作り、このパーティションをルート(/)にマウントすることで 100GB の容量を持つファイルシステムとなります:
2025090502


ここまでだと結局どちらも 100GB の空間を持つファイルシステムが作られることになり、同じことのように見えてしまって、PV と LV の違いが分かりにくいと思います。違いを分かりやすくするためにもう1つ、別に「容量 200GB のディスク /dev/sdb」が手元にあると仮定します。

PV で考えると、この 200GB のディスク /dev/sdb は先ほどの 100GB のディスク /dev/sda とは完全に別のディスクという扱いになります。「容量が 100GB のディスクA」と「容量が 200GB のディスクB」という2つのディスクです。Linux の機能を使って、ディスクAをルートディスク(/)として、ディスクBを /home にマウントすることはできますし、その場合「両方合わせて 300GB」にはなります。しかしディスクAに余裕があったとしてもディスクBに余裕がなければ /home にデータを追加できなくなってしまいます:
2025090503


一方 LV で考えるとこの辺りを柔軟に考えることができるようになります。もともとディスクAをまるごと使って VG を作成していましたが、更にディスクBも同じ VG に追加することができます。この場合、この VG のサイズ(つまり LV のサイズ)は 300GB になります。ディスクBに(物理的な)余裕がなかったとしても、ディスクAに余裕があれば LV にデータを追加可能です。仮にディスクA、B両方の余裕がなくなってしまった場合も、更に別の物理ディスクCを VG に追加することで、動的に VG/LV を拡張することが可能です:
2025090504


1点注意が必要なのは、この論理的な LV の空間が linux のどのディレクトリにマウントされているかです。例えばルートディスクは別に存在していて、 この LV が /mnt にマウントされていた場合、/mnt 以下には最大 300GB のデータを格納することができますが、それ以外のディレクトリ(/usr など)はルートディスクの空きを意識する必要がある、という点です。

なお、1つの VG を1つの LV にする必要はありません。物理ディスクをパーティショニングする時のように、1つの VG から複数の LV に分けて使うことも可能です。



Linux では複数ディスクを論理的に扱う VG/LV という概念があることを説明しました。次回はこの考え方を使って、ルートディレクトリを LV で作り、後からルートディレクトリを拡張する具体的な手順を紹介予定です。




IBM COBOL for Linux 1.1 がリリースされたので、入手できる立場を利用して(笑)使ってみました。


このソフトウェアを使える権利をお持ちの方は IBM のダウンロードページで "IBM COBOL for Linux" を検索すると見つかります。ちなみに x86_64 の RHEL 7 or 8 または Ubuntu 16 or 18 or 20 の LTS リリースがサポートプラットフォームとされています。インストーラーを含む実行バイナリは CC7XYML で検索して見つかるものです:
2021042000


実行バイナリ(COBOL_LINUX86_6.1.tar.gz)を展開すると以下のようなファイルが入手できます。この中の install というファイルがインストーラーです:
2021042001


この install を実行すると実行環境に合わせた標準インストールが実行されます。インストール先フォルダの指定などはできないのですが、インストール時の前提ライブラリなども合わせて導入されるため非常に簡単にインストールできます:
2021042002


RHEL で実行した場合は足りない前提ライブラリが yum でインストールされます:
2021042003


インストールが成功すると "Installation and configuration successful" というメッセージが表示されます。標準インストールの場合、/opt/ibm/cobol/1.1.0/ 以下にモジュールが格納されます:
2021042004


実際に COBOL のプログラムを作ってコンパイルしてみます。とりあえずは Hello World をみようみまねで・・・
2021042005


そしてコンパイラ(/opt/ibm/cobol/1.1.0/usr/bin/cob2)でコンパイル・・・・
2021042006


・・・エラー!?
2021042007


(知らなかったのですが)COBOL は行のどの位置に記述するかによってコードの意味が変わるらしいです。この例では DISPLAY 命令を書く位置を(「タブ=スペース2」派の僕が勝手にインデント数を減らして)変えてしまったので、その意味合いが変わってしまったことが原因のようでした。というわけで、正しい位置に変更:
2021042008


そして再コンパイル、今度は成功しました:
2021042009


そして実行。ちと躓きましたが(苦笑)、無事に Hello World を表示できました:
2021042010


では今度はこいつを CGI 化してウェブブラウザから・・・と考えていたのですが、調べていて不毛な気がしてきて(苦笑)、もう少し別の形でウェブ対応する方向を考えます。できたらここで紹介する予定です。

(2021/04/26 追記)
上述の COBOL 版 Hello World を公開しました:
https://github.com/dotnsf/hello-cobol



Twitter や facebook ではそれなりの頻度で触れている話題なのですが、9月末にキングジムのポメラ DM200 を購入しました:
1 開封


小型 PC(といっていいのか?)の中では抜群のキーボード操作性を持ち、テキスト入力作業中心に使う人からの人気が高い機種です。ただ自分の場合は購入当初から普通にテキスト入力機として使うつもりはなく、Linux(Debian) 化できることを理解して、Linux 化して使うつもりで購入しました。DM200 の Linux 化手順や Linux 化直後の各種ツールの導入については以下の2つのサイトが有名で、実際に自分も大変お世話になりました。先人たちの努力で Linux 化は非常に簡単でした。感謝を意を表すと同時に、DM200 の Linux 化についてはこちらを参照いただけると一連の手順が非常にわかりやすくまとまっています:
pomera DM200 の Linux 化のメモ
KING JIM ポメラDM200でEmacs、Vim、Ruby、Pythonが動くなんて素敵すぎる!


実際に自分も日本語環境を含めて X Window 対応を行い、普段使いの PC でも使っている開発者エディタである VSCode を導入したり、オフィススイートである LibreOffice を導入したりしてみました。DM200 はメモリが 0.5GB しかないこともあり、正直なところ VSCode や LibreOffice はちと重すぎで、軽快な作業というわけにはいかないアプリでした:
3 vscode


一方で X Window を使わなければ充分に軽快なテキスト編集マシンとして使えそうだという感触は持っています。ただ X Window 自体が悪というわけではなく、「重さを感じるかどうかは X Window 上で動かすアプリケーション次第」だと思っています。画像編集アプリとか、FireFox のような重めのアプリだと厳しそうですが、軽いアプリなら X Window でもまあ苦にはならないな、という印象です:
6 scratch


この DM200 の Linux 化環境、なんといっても(アーキテクチャが同じなので)「ラズベリーパイ向けの資産の多くが使える」のです。重い X Window アプリだから使わない、というのはあまりにもったいないと思いました。今の所の自分の感覚では
・テキスト入力
・コーディングや動作確認を含めたプログラミング
・SSH などによるリモート操作端末
としての利用であれば、最高に使いやすい物理キーボードと合わせて快適に使える環境だと思っています。

そんな自分が現時点で DM200 に導入してよく使っているアプリケーションをいくつか紹介させていただきます。なお特にリンクをつけていないものは上述のページの手順内で紹介されているものか、標準作業で導入されるものです。


【日本語テキスト入力用】
- uim-fep
- IBus
- vi/vim

日本語FEPとテキストエディタという、本来のポメラが得意とする使い方を Linux でも使う、というものです。この使い方に限っては Linux 環境ではなく、普通のポメラとして使ったほうが(便利な各種辞書なども併用できるなど)便利であるとは思います。 ただ入力したテキストをインターネットを使って外部とやりとりする段になった時に Linux 環境であったほうが断然便利で、自分はそのように使うことが多いので、困らない限りは Linux 環境で入力も行っています。

また当初は screen や tmux といったターミナルマルチプレクサーも使っていましたが、ALT + Fn キーで端末を切り替えたり、X Window であればターミナルを複数起動したりすることで同様の操作ができるのであまり使わなくなりました。ちなみにターミナルが複数必要な理由ですが、DM200 の Linux で無線LANやBluetooth(外部マウス)の有効化/無効化時に root 権限での作業が必要※になり、切り替えが面倒だったのでターミナルごとわけて使っている、という背景があります。

※普通の PC のように両方ともはじめから有効にしておけばいい、という声もあると思いますが、この2つはどうも互いに干渉するようで、なるべくなら両方有効にはしたくないという事情と、無線 LAN については使う環境で接続先を切り替えて使うことになるのですが、その切替にコマンドライン操作が必要という事情があるのでした。


【プログラミング用】
- Node.js
- Uzbl
- ngrok
- cf cli

ある意味「このためにポメラ DM200 を購入した」という使いみちでもあります。まず自分の普段のメイン開発言語が Node.js なため、Node.js & npm を導入しています。またウェブアプリケーション開発時の動作確認用にウェブブラウザが必要なのですが、FireFox が重いので Uzbl という軽量ブラウザを使っています。軽量で便利な一方、JavaScript の互換性が充分ではないので、多少苦労することもあります。

ngrok はローカルで開発したアプリケーションを一時的にインターネットに公開する IP フォワードツールです。一時的とはいえ、外部の人にも使ってもらえるようになるのがとても便利。

で、ある程度動くようになったらサービスとして公開するのですが、その際に安価な IBM Cloud の Cloud Foundry 環境で公開することが多く、その時に cf cli ツールを使います。

その他 git なども使ってますが、ほぼ最初から導入済みの環境なので割愛します。

おまけでプログラミング環境として Node-RED や Scratch も導入できました($ sudo npm install -g nodered や $ sudo apt-get install scratch で導入できます)。ただ自分自身がこの環境をあまり使うわけではないのと、Node-RED を localhost で動かす際のブラウザが Uzbl だとちゃんと動かない箇所があったりしてイマイチな感じ(FireFox とか使えばいいんでしょうけど重くて・・):
5 nodered


【リモート操作端末用】
- SSH
- OpenVPN クライアント
- VNC Viewer
- x3270

DM200 購入時点ではあまり想定してなかった使いみちでしたが、使い勝手のいいキーボードや、DM200 の(Linux としての)非力さを補う使い方という相性の良さもあって、使いみちの中心がこのリモート操作端末に移行しつつあります。

リモート操作のほとんどは SSH で済ませています。ただその際に VPN 接続が必要な場合もあり、その場合は OpenVPN クライアントで接続しています(普通に $ sudo apt-get install openvpn で導入できます):

(↓ 右のターミナルで OpenVPN して、左のターミナルで SSH 接続してます)
8 ssh


また VNC Viewer を使ってデスクトップ環境へリモート接続も可能です。このあたりはラズベリーパイと同じアーキテクチャであることで、多くのツールが DM200 でも使えるメリットを生かしています:
s4QNvdc


ほとんどの人は不要だと思いますが、3270 と呼ばれるホスト端末のエミュレーターを使うことがあります。自分は上述の x3270 のフリーソフトを使っています。ソースコードからビルドする必要がありますが、普通に $ ./configure && make して、 $ sudo make install で導入できます。



といった具合で使っています。もともとは出先でのプログラミングマシンとして購入したのですが、クラウドなどの各種サーバーにログインして操作するための環境としての便利さにも気づき、今は利用用途が半々くらいになっています。なんといってもキーボードで不便さを感じずに使えることがストレス無く利用できて、素晴らしく便利です。


Windows 10 でサポートされるようになった WSL(Windows Subsystem for Linux) 、しばらくメイン機が Windows 7 のままだったので、あまり使うこともなかったのですが、業務用のマシンも5月に Win10 に置き換えられることになったことと、プライベートで購入した GPD Pocket 2 を開発機として活用する目的もあって、これまで以上に気合を入れて使ってみることにしました:
windows-vs-ubuntu



【これまでの開発スタイル】
WSL の話の前に、これまでの自分の開発スタイルを簡単に紹介しておきます。基本 Linux 上でソースコードを書いて、同 Linux 上で動かしてテストしていました。最大の理由は「本番で動かす際のサーバーはほぼ Linux 」かつ「自分は vi エディタ派」だからでした。一方、業務で支給されているマシンはメイン機が Windows (7) ノートPCで、サブ機が macOS デスクトップ(iMac)、個人で所有する中に Ubuntu デスクトップ機が1台存在する、という状態でした。つまりコーディングする時は
  • Windows に Linux の仮想マシンを入れて、そちらにログインしてコーディング
  • Windows から別環境の Linux(クラウドとかラズパイとか)にリモートログインしてコーディング
  • macOS 上のターミナルからエディタを起動してコーディング
  • Ubuntu デスクトップをインストールしたノート PC からコーディング
するような感じでした。

なお Windows 上でコーディングして Windows 上で動作テスト、というスタイルは本番サーバーが Windows とわかっていればやるかもしれませんが、色々挙動の違いが気になってしまい、あまりやっていません。

上記4つのうち、上2つは面倒なんですが、本番環境に近い Linux 上での動作確認までできるという点が魅力です。また開発以外の資料作成時にデスクトップアプリ(パワポ、エクセル、ノーツ、画像リタッチ、あと ATOM みたいな IDE 環境、etc・・・)を利用する際においては使いやすい Windows 版が使える点が魅力でした(ぶっちゃけ、macOS 版のエクセルや日本語変換の完成度って・・・(^^; )。一方で実質的には開発用に(仮想的な)別環境を1つ作る必要があるため、ディスク利用効率もよくないし、その点においては資料作成含めてすべて1台の macOS 内で完結できる3つ目の開発スタイルも、これはこれで優れていると感じていました。 4つ目の Ubuntu デスクトップ機を使うのも3つ目と同じで悪くはないのですが、やはり開発作業以外のデスクトップ作業では Windows に一日の長があるように感じます(Micorsoft Office も Linux 版は提供されてないし)。Ubuntu でプレゼン資料作るのはまだちと厳しいと感じる現実があります。


【WSL を併用した開発スタイル】
今回 WSL を使って開発環境を構築するにあたり、このような責任分担を行いました:
サーバー部分: WSL
開発・デスクトップ作業: Windows


つまり、ソースコードを置いたり、アプリケーションサーバーを起動したり、そのアプリケーションサーバーから開発したアプリケーションを起動したりする部分は WSL を使います。 一方、ソースコードを編集したり、ソースコード以外の資料ファイル作成など(ウェブでググるのも含める)といった GUI のデスクトップ作業は Windows を使うことにします。それぞれの得意分野を活かせるような分担にしたつもりです:
2019040800



この環境で開発作業を行うために2点ほど環境設定を行いました:

(1) ソースコード共有
サーバーが WSL で、クライアントおよびデスクトップ作業は Windows 。と、キレイに分けているように見えるかもしれませんが、ソースコードだけは共有する必要があります。つまり Windows(クライアント)側でソースコードを編集し、その編集されたソースコードが WSL 上で実行される必要があるのでした。

このため以下の手順を実行して、Windows / WSL 両方の環境から1つのソースコードが参照できるようにしました。まず Windows のコマンドプロンプトを起動し、ホームディレクトリに src/ という名前のフォルダを作成しました。ソースコードはこのフォルダ内に作ります:
> cd \Users\(Windows のユーザー名)

> mkdir src


次に WSL のシェルを起動して、上記で作成した src フォルダをホームディレクトリにシンボリックリンクします。WSL からは Windows の C ドライブが /mnt/c/ フォルダにマウントされています。この情報から上記で作成したフォルダは /mnt/c/Users/(Windows のユーザー名)/src に作られていることになるので、WSL のシェル上で以下のように実行します:
$ cd

$ ln -s /mnt/c/Users/(Windows のユーザー名)/src

これで Windows のホームディレクトリ以下に作成した src フォルダが、WSL では ~/src フォルダとして存在するようになりました。これで Windows で編集したファイルを WSL からも参照できるようになったので、そのまま WSL のアプリケーションサーバー上で動かすことができるようになりました。


(2) ATOM エディタの vim 化
次に Windows 向けのテキストエディタのカスタマイズです。個人的に vi/vim 派なので、テキストエディタでもこのキーバインドを使いたいのでした。

例えば Windows 向けの vim を導入する、というのも1つの案だと思いますが、自分は ATOM エディタに vim 用プラグインを導入して vim っぽく(?)使えるようにカスタマイズしました。

具体的には(ググればわかると思いますが)ATOM エディタに vim-mode-plus プラグインを導入して、ATOM を vi/vim キーバインドで使えるようにしています。


これら2つのカスタマイズによって、
①アプリ開発時に、まず Windows で WSL と ATOM を起動し、
②ATOM でソースコードを編集し、
③WSL 側で編集したソースコードをアプリケーションサーバーで起動してテスト、
④Git へのコミットや本番サーバーへのデプロイは WSL から行い、
⑤ドキュメントや資料は Windows の Office やデスクトップツールで作成
という、かなり使い勝手のよい作業分担環境を作ることができました。

一方でこの環境を使う場合の注意点もあります。最大の問題は「文字コードの違い」を意識する必要があることです。Windows 側で編集するソースコードの文字コードは原則 UTF-8 にする点に注意しましょう。

WSL はまだ動かないツールがあったり、デーモンは手動起動が必要になるなどの制限事項もありますが、ウェブアプリケーションの開発環境として使う限りにおいてはあまり苦にならないと思いました。


恥ずかしながら、今回紹介する Linux の sc コマンドの存在を全くしりませんでした。。


sc(spreadsheet calculator) コマンドは UNIX/Linux のコンソールから使える表計算アプリケーションです。X Window で動作する GUI アプリではなく、あくまで CUI のコンソール上で動く表計算アプリケーションです。オッサン的には DOS 時代の Lotus 1-2-3 を彷彿とさせる画面に胸騒ぎを禁じえません:
2018042900


インストール方法はソースからビルドするものも含めて数通りありますが、Debian ベースの Ubuntu や Raspberry Pi であれば、apt-get コマンドを使って普通に導入できます:
$ sudo apt-get install sc

このコマンドを実行するだけで導入できます。私のラズパイで実行した時の様子がこちら↓です。コマンド実行前のライブラリの導入状況も含めた環境にも依存するとは思いますが、私の環境ではアプリケーション全体で 369 キロバイト( 0.37 メガバイト)しか使いませんでした。超軽量アプリです:
2018042901


インストール後、プロンプトで "sc" を実行すると起動します:
2018042902
 (↑ DOS 版 Lotus 1-2-3 を知っていると、この時点で感動の涙モノ)


起動後の使い方は '?' キーを入力することで参照できますが、ざっと調べた限りでカーソル移動を含めた主なものはこちらです。いわゆる vi エディタのコマンドに近い操作体系になっているので、vi 派であればすぐに使えるようになると思っています:

操作キー解説
カーソル移動(上下左右)方向キーまたは kjhlvi キーバインド
数値入力カーソル位置で = を入力してから数値を入力
文字入力カーソル位置で > を入力してから文字を入力
値の削除カーソル位置で x を入力vi キーバインド
足し算・引き算などカーソル位置で = を入力してからセルを指定して A0 + A1 のような式を入力
終了q


機能的に Excel と比較するようなレベルのものではありませんが、むかーし 1-2-3 の製品開発に関わっていた自分的にはノスタルジックを越えた何かを感じるツールです。

このページのトップヘ