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

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

タグ:ubuntu

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 の設定を変えたい時)でもラズパイを使えて、とても便利な接続方法です。アナログ最強!

 

Ubuntu (や CentOS/RedHat Enterprise Linux)をデスクトップとして使っている人はあまり多くないかもしれませんが、自分はその1人です。知る人ぞ知る GPD Pocket も Ubuntu モデルを購入しました。

個人的には最近の Linux デスクトップは非常に便利だと思ってますが、ただ使っていて「あれ??」と思うことが無いわけでもありません。例えば今回紹介するのは MPEG4 動画の再生なんですが、そのコーデックは標準で充分にインストールされているわけではないので、そのままでは再生できないことがあります。その Ubuntu 環境での導入方法を調べたのでメモ目的も兼ねてブログにします。


まず、MPEG4 AAC コーデックなどの拡張メディア機能を Ubuntu に導入するには ubuntu-restricted-extras というパッケージをあらかじめ導入しておく必要があります。以下のコマンドで導入します:
$ sudo apt-get install ubuntu-restricted-extras

その後、必要なメディアパッケージを導入します。今回の MPEG4 であれば以下のコマンドでインストールします:
$ sudo apt-get install libav-tools ffmpeg


これで MPEG4 AAC や H.264 デコーダーが導入されて、Ubuntu デスクトップからも再生可能になります。





前回の続きです:
Ubuntu で Swift 言語を使う


前回は Ubuntu 上に Swift アプリケーション開発環境を用意して、ハローワールド的なアプリケーションを作って実行するまでを紹介しました。今回は Swift 用の Web アプリケーションフレームワークである Kitura を使って、Ubuntu 上の Swift で Web アプリケーションを開発してみます。 以下の作業の前に前回紹介した導入作業が必要になるので、まだの場合はこちらを参照して Ubuntu に Swift をインストールしておいてください。

では改めて Kitura アプリケーションを作ってみます。前回同様にアプリケーションプロジェクト用のディレクトリ(以下の例では myFirstKitura)を作って移動し、swift コマンドでパッケージを初期化しておきます(ここまでは前回と同様です):
$ mkdir myFirstKitura
$ cd myFirstKitura
$ swift package init --type executable

このプロジェクトでは Kitura を利用するため、パッケージ情報に dependencies を記述する必要があります。Package.swift ファイルをテキストエディタで開き、以下の青字部分を追加します:
import PackageDescription

let package = Package(
    name: "myFirstKitura",
    dependencies: [
        .Package(url: "https://github.com/IBM-Swift/Kitura.git", majorVersion: 1, minor: 6)
    ]
)

そしてアプリケーションのソースコード Sources/main.swift を以下のように変更します。Kitura の HTTP Server を使って 8090 番ポートで待ちうけ、"/"(ドキュメントルート)への GET アクセスをハンドリングしてメッセージを表示する、という内容にしています:
import Kitura

// Create a new router
let router = Router()

// Handle HTTP GET requests to /
router.get("/") {
    request, response, next in
    response.send("ハローワールド!")
    next()
}

// Add an HTTP server and connect it to the router
Kitura.addHTTPServer(onPort: 8090, with: router)

// Start the Kitura runloop (this call never returns)
Kitura.run()
  ↑なんとなく Node.js の Express に似てます。。


ではこのコードをビルドして実行します:
$ swift build
$ ./build/debug/myFirstKitura (実行したままにします)

実行されている状態で、同じシステムのウェブブラウザから http://localhost:8090/ にアクセスし、コードに記述したメッセージが表示されることを確認します:
2017040402


ウェブアプリケーションとして稼働できていることが確認できました。実行したままになっているコマンドを終了するには Ctrl + C を実行します:
$ ./build/debug/myFirstKitura
^C  (Ctrl+C を実行して、コマンドプロンプトに戻る)
$


以上、簡単なサンプルでしたが、Web のルーティング機能が実装されたフレームワークで Swift アプリケーションを、macOS ではなく Ubuntu 環境で開発/実行することができるようになりました。この Swift ウェブアプリケーションは IBM BluemixSwift ランタイムとしても実装されており、作ったアプリケーションを Bluemix 上ですぐに運用することができます:
2017040403



(参考)
http://www.kitura.io/en/starter/gettingstarted.html


このページのトップヘ