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

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

タグ:ubuntu

Ubuntu ベースの環境(ラズパイなども含む)にアプリケーションを追加インストールする際には apt コマンドを使います。例えばこんな感じ:
$ sudo apt install nginx
※ apt の代わりに apt-get を使うこともありますが、現在推奨されているのは apt コマンドらしいです。

このコマンドは Ubuntu システム標準のソースリポジトリにあらかじめ nginx が登録されていて、その中で具体的に必要なモジュール一式やその導入手順が参照できるようになっていることで実現しています。インストールコマンドとしては上記のたった1行のコマンドで済むようになっていますが、実際には最新バージョンがいくつで、その導入にはどのような依存モジュールのどのバージョンが必要で、現在のシステムに導入済み(インストールの必要ないもの)は何で、、といった情報が参照され、必要なモジュールだけがインストールできるようになっています。

が、たまにこのコマンドだけではインストールできないことがあります。原因はいくつかありますが、その1つが「対象アプリケーションが標準のソースリポジトリに登録されていない」場合があります。要は目的のアプリケーションをインストールする手順や依存ライブラリが標準構成のソースリポジトリには登録されていないのでインストールできない、ということになります。例えば CloudFoundry の CLI ツールである cf (アプリ名としては cf-cli)をそのまま apt コマンドでインストールしようとしても以下のようなエラーになります:
$ sudo apt install cf-cli
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package cf-cli

このように標準ソースリポジトリに登録されていないことが原因でインストールできない(が、別のソースリポジトリを登録すればよい)場合は、対象アプリケーションが登録されたリポジトリを登録しなおしてあげればインストールできるようになります。

リポジトリを登録し直す方法はアプリケーションによっても異なるのですが、例えば上述の cf-cli の場合は公式ドキュメントによると以下の手順でリポジトリを登録できるようです:
$ wget -q -O - https://packages.cloudfoundry.org/debian/cli.cloudfoundry.org.key | sudo apt-key add -

$ echo "deb https://packages.cloudfoundry.org/debian stable main" | sudo tee /etc/apt/sources.list.d/cloudfoundry-cli.list

このコマンドの最後に /etc/apt/sources.list.d/ ディレクトリ内に cloudfoundry-cli.list というファイルを作成して登録しています(apt-add-repository コマンドを使って登録する方法もありますが、その場合も同ディレクトリ内にファイルが追加されます)。

なお、このようにソースリポジトリに変化があった場合はインストール前にキャッシュ内容を更新する必要があります:
$ sudo apt update

更新後は cf-cli がインストール可能です:
$ sudo apt install cf-cli

ここまでは apt の仕組みなどにあまり詳しくなくても、インストール手順を調べながら詳しく知らずに実行していることもあると思っています。


さて、問題はここからです。自分も知らなかったのですが、このように「標準構成以外に追加登録したリポジトリ」を削除したい、つまり追加登録しなかった状態に戻すにはどのようにしたらいいでしょうか? これ、意外と情報を見つけるのが難しくて苦戦したのでした。その備忘録としての本ブログでもあります。

答は以下です。3段階の手順が必要でした(特に (2) を忘れがち)。

(1) /etc/apt/sources.list.d/ 以下に追加された該当ファイルを削除する
$ sudo rm /etc/apt/sources.list.d/cloudfoundry-cli.list

(2) 記録された該当キーを見つけて削除する
$ apt-key list

(結果の一覧から cloudfoundry-cli のキーを見つける。仮に "1234ABCD" だったとする)

$ sudo apt-key del 1234ABCD

(3) リポジトリ更新
$ sudo apt update


無事にリポジトリ情報を削除して、削除した状態で更新できました。めでたしめでたし。



【参考】
https://unix.stackexchange.com/questions/219341/how-to-apt-delete-repository



そろそろ、その時はやって来たかな?
時は来た!


これまでメインのプログラミング開発環境を Windows10 の WSL(Windows Subsystem for Linux)Ubuntu 18.04 にしていました。WSL2 のことはもちろん知っていましたが、メイン機のスペックが特別高いわけでもなく(メモリ 8GB)、WSL で困らないであろう範囲のプログラミングをメインにしていました(例えばコンテナ環境が必要になった場合は別環境に用意して、そこにアクセスする、など)。

一方で WSL2 をサポートする開発周辺環境も整ってきました。Docker Desktop for Windows もリリースされ、もう mac と比較しても「アプリ開発環境は Windows 機 + WSL2 でいいんじゃないか?」と思える状況になってきました。スペック面での不安がないわけじゃないけど、環境的な意味では「時は来た」かな、と。

というわけで、自分の WSL 環境を WSL2 環境へ移行することにしました。以下その手順を備忘録として残しておきます。


【Hyper-V を有効化】
まず Windows の Hyper-V を有効化する必要があります。既に Hyper-V が有効になっている環境であればこの手順は不要ですが、今回はここも含めて紹介します。

その手順で利用するため Windows で PowerShell を起動します。この際に管理者権限で起動しておくようにします(バージョン確認だけなら管理者権限は不要ですが、WSL を WSL2 に変更する際に管理者権限が必要になります)。

そして以下のコマンドを実行します:
> Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

そしてこのコマンドを実行後に再起動をかけると Hyper-V が有効化されます。ここから以下の作業は再起動後に行ってください。


(↓2020/11/22 追記)
【Windows ハイパーバイザープラットフォームの有効化】
VirtualBox など、他のハイパーバイザー環境との共存のための機能を有効にします。

Windowsの機能の有効化または無効化から Windows ハイパーバイザープラットフォームを選択して、チェックを入れて OK をクリックします:
2020112201
(↑2020/11/22 追記)


【WSL のバージョンを確認】
ここから下の PowerShell での操作については(管理者権限の)コマンドプロンプトでも構いません。

Hyper-V を有効にして再起動後、まず現在利用中の WSL のバージョン(1のはず)を確認しておきます。PowerShell で以下のコマンドを実行します:
> wsl --list --verbose

すると以下のような結果になり、WSL(1) を使っていることが確認できます:
2020112101


【WSL の Linux カーネルを更新】
この WSL を WSL2 に変更するのですが、その前に WSL の Linux カーネルを最新版に更新しておきます。

まず以下へアクセスします:
https://docs.microsoft.com/ja-jp/windows/wsl/wsl2-kernel


「最新の WSL2 Linux カーネル更新プログラムパッケージをダウンロード」と書かれたリンクから更新パッケージをダウンロードします:
2020112102


ダウンロード後に実行して、WSL の Linux カーネルを更新します:
2020112103


【WSL を WSL2 に変更】
ここまでの準備ができていれば WSL を WSL2 に変更する準備が整いました。管理者権限の PowerShell で以下を実行して、まずは WSL のデフォルトバージョンを 2 に変更します(一瞬で終わります):
> wsl --set-default-version 2

続けて以下のコマンドも実行し、現在 WSL で動作中の Ubuntu 18.04 を WSL2 に変更します(少し時間がかかります):
> wsl --set-version Ubuntu-18.04 2

2020112101


これで WSL2 になった、はず。。


【WSL のバージョンを再確認】
最後に WSL のバージョンが2になっていることを確認します。再度先程と同じコマンドを実行し、バージョンが更新されていることを確認します:
> wsl --list --verbose

2020112102


WSL1 から WSL2 への環境移行に成功しました。

Windows 10 で kubernates の開発環境を構築する際の方法の1つとして、以下のケースで構築する場合のメモです:
・Kubernetes 本体は minikube を使って Windows 10 に導入
・kubectl は WSL から利用


Kubernetes 本体はローカルで動く minikube を使ってシングルノード環境を構築します。この部分は正しく導入できていさえすれば Windows だろうが、Linux だろうが、Mac だろうが、システム環境の違いを意識することはあまりないと思っています。 ただ実際に利用する段になって kubectl コマンドを実行する環境としては Windows よりもより実践に近い Linux を使いたくなります。というわけで、Windows 10 の WSL (今回は Ubuntu を想定)から利用できるようにしました。

なお、この環境構築をする場合のマシンスペックとして、メモリ 8GB だと構築して minikube start した時点でほぼメモリを使い尽くしてしまいます。動作確認するだけならいいのですが、本格的に開発して動作確認してテストして・・・という段階まで考えるとやはり 16GB くらいはほしいところです。


【前提条件】
- Windows 10
- WSL(Ubuntu 18.0.4) 導入済み


【VirtualBox のインストール】
Windows 10 で minikube を動かす場合、仮想環境のハイパーバイザーが必要です。今回は VirtualBoxを使います。VirtualBox 自体のインストールはごく普通に公式ページから Windows 版をダウンロードし、デフォルト設定のままインストールすればOKです。


【Windows 版 minikube のインストール】
minikube の Github ページから、Windows/amd64 版の minikube 単体をダウンロードします:
2019090801


ダウンロードしたファイルは minikube-windows-amd64.exe というファイル名になっていますが、これを minikube.exe とリネームしてファイルシステムの適当なフォルダに保存します(以下は C:\MyApps\minikube\ というフォルダを作成して、その中に C:\MyApps\minikube\minikube.exe という名前で保存しているものと仮定して以下を続けます)。

このフォルダに PATH を通します。Windows + S キーを押して検索ボックスに「システムの詳細設定」と入力すると「システムの詳細設定の表示」が見つかるので、これを選択します:
2019090802


システムのプロパティウィンドウが表示されたら、「詳細設定」タブを選択し、「環境変数」ボタンをクリック:
2019090803


ユーザー環境変数の Path を選択してから「編集」ボタンをクリック:
2019090804


そして「新規」に minikube.exe が保存されたフォルダ名を追加して、最後に OK ボタンをクリック。これで minikube.exe に PATH が通りました:
2019090805


念の為、動作確認してみます。コマンドプロンプトを起動して、 "minikube version" と入力して実行します。minikube のバージョン番号が表示されれば、ここまでの手順は OK です:
2019090801


【minikube の起動】
コマンドプロンプトから "minikube start" と入力して、minikube を起動します。自動的に必要な VM イメージを見つけて(初回はダウンロードして)自動構築します。通常は minikube が kubectl を見つけてくれるのですが、この方法だと(Windows 版 kubectl を使わない&インストールしていないので)見つからない、という警告が表示されますが、今回は WSL 側に kubectl を用意するので無視します:
2019090802


【WSL に kubectl をインストール】
WSL を起動し、以下のコマンドを入力して kubectl を(/usr/local/bin/ 以下に)導入します:
$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl

$ chmod 755 kubectl

$ sudo mv kubectl /usr/local/bin

最後に "kubectl version" を実行して動作確認します(初回は Client Version が表示されれば OK です):
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.3", GitCommit:"2d3c76f9091b6bec110a5e63777c332469e0cba2", GitTreeState:"clean", BuildDate:"2019-08-19T11:13:54Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

【minikube のエンドポイント情報の取得】
コマンドプロンプトに戻って、"minikube status" を実行し、minikube のエンドポイント情報を確認します。以下の例では 192.168.99.100 というアドレスが表示されていますが、これにポート番号 8443 を加えたもの(192.168.99.100:8443)がエンドポイントとなり、以下で利用することになります:
2019090803


【kubectl の設定】
上記で取得したエンドポイント情報を使って kubectl の設定を行います。WSL から以下のコマンドを順次実行します。なお以下で <コマンドプロンプト実行時のユーザー名> と表示されている部分にはコマンドプロンプト実行時のユーザー名がフォルダ名の一部になっているのでそれをそのまま指定します(上記の画像例の場合であれば、ここには KEIKIMURA が入ります)、また 192.168.99.100:8443 部分は上記で取得したエンドポイント情報です:
$ kubectl config set-credentials minikube --client-certificate=/mnt/c/Users/<コマンドプロンプト実行時のユーザー名>/.minikube/client.crt --client-key=/mnt/c/Users/<コマンドプロンプト実行時のユーザー名>/.minikube/client.key

$ kubectl config set-cluster minikube --server=https://192.168.99.100:8443 --certificate-authority=/mnt/c/Users/<コマンドプロンプト実行時のユーザー名>/.minikube/ca.crt

$ kubectl config set-context minikube --user=minikube --cluster=minikube

$ kubectl config use-context minikube

最後に WSL で "kubectl cluster-info" コマンドを実行して動作を確認し、エンドポイントで正しくクラスタ状態が取得できれば kubectl の設定完了です。シングルノードの kubernetes (kubectl) がローカルの WSL から使えるようになりました:
$ kubectl cluster-info

Kubernetes master is running at https://192.168.99.100:8443
KubeDNS is running at https://192.168.99.100:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.



(参考)
https://dokupe.hatenablog.com/entry/20180408/1523116886

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


アマゾンで PC とラズベリーパイをシリアル接続する USB ケーブルを購入しました:
Raspberry Pi ラズベリーパイ用の USB-TTLシリアルコンソールのUSB変換COMケーブルモジュールのケーブル


これ、Windows ではデバイスドライバも提供されていて、Teraterm などでシリアル接続できることがよく知られています。では Ubuntu (16.04) で同様のことができるのか? ということに挑戦してみました。結論としては特別にデバイスドライバを用意することもなく、アクセスすることができました。以下、その手順です。


まずはラズベリーパイの設定(raspi-config)でシリアル接続を有効にします。raspi-config で Interface - Serial を選択します:
2018081701


「はい」を選んでシリアル接続を有効にします:
2018081702


次にラズベリーパイと USB シリアルケーブルとを接続します。USB シリアルケーブルの黒(GND)をラズパイの6番ピン、白(UART TXD(14))を8番ピン、緑(UART RXD(15))を10番ピンにそれぞれ接続します。赤は結線の必要がないので宙ぶらりんのままです:
IMG_2932


次に Ubuntu 側の準備です。実は特別にデバイスドライバを準備することもなく、そのまま認識されます。が、ただ認識しただけでは通信はできないため、そのための準備が必要です。

まず、今回のシリアル通信には cu コマンドを使います。なので、まずは cu をインストールします:
$ sudo apt-get install cu

次にシリアルポートの確認と設定を行います。Ubuntu の USB ポートに USB シリアルケーブルを接続し、次のコマンドを入力して、ちゃんと認識できているかどうかを確認します:
$ ls -l /dev/serial/by-id/

USB シリアルケーブルが正しく認識できていると /dev/ttyUSB0 といった感じで最後に 0(ゼロ)が付いたデバイスとして認識されます。今回は /dev/ttyUSB0 として認識されていると仮定して以下の説明を続けます:
20180814a


/dev/ttyUSB0 の権限を変更します:
$ sudo chmod 666 /dev/ttyUSB0

ここまでの手順で準備が完了しました。最後に cu コマンドで目的のデバイスに接続します。その際にボーレートを 115200 bps に指定して接続します:
$ sudo cu -s 115200 -l /dev/ttyUSB0

成功するとこんな感じでラズパイのログインプロンプトが現れ、ログインできます:
20180814


モニタがないとか、無線LAN がないとか、無線 LAN の環境が普段と違う時(の無線 LAN の設定を変えたい時)でもラズパイを使えて、とても便利な接続方法です。アナログ最強!

 

このページのトップヘ