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

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

2019年04月

久しぶりに IBM Cloud の Kubernetes サービスを使ってみたら、色々変わっていたので、自分の備忘録を兼ねてまとめてみました。そういえば IBM Cloud(Bluemix) 記事を書くのは久しぶりかも。。 (^^;

まず、現在 IBM Cloud では無料で1ワーカーノードの Kubernetes サービスが使えます。ここで少し注意が必要です。IBM Cloud にはライトプランと呼ばれるアカウント・プランがあり、クレジットカードすら不要な登録作業によって無料で IBM Cloud のアプリケーション・サーバーやデータベースといったサービスを一定量ですがずっと使うことができます(どこかみたいに12ヶ月無料、とかではありません)。これはこれで非常に便利なアカウントプランなのですが、今回紹介する「無料の Kubernetes サービスがライトプランで使えるわけではない」という点に注意が必要です。 詳しくは後述しますが、この無料の Kubernetes サービスは(有償の)スタンダードアカウント向けに無料で提供されているサービスプランの1つです。つまり前述のライトプランで使えるものではない、という点に注意が必要です。自分はスタンダードアカウントを持っているので、それを使って以下の確認作業を行いました。


というわけで、実際に無料の Kubernetes サービスを利用するにはスタンダードアカウントで IBM Cloud にログインする必要があります。そしてログイン後に「リソースの作成」をクリックします:
2019041101


利用するサービスをカタログから選択します。今回は「コンテナ」カテゴリから「Kubernetes Services」を選択します:
2019041102


次の画面では有料のものも含めたサービスプランの種類が一覧で確認できます。無料(free)プランではワーカーノードが1つという制限がありますが、料金はかからないことが確認できます。また今回の説明の対象ではありませんが、有料プランの場合の各ノードのスペックと料金を確認することもできます。ここではとりあえず「Create」ボタンをクリックします(ライトプランだと、この「Create」ボタンが押せないはずです):
2019041103


次の画面で Kubernetes クラスタのタイプを指定します。まずデフォルトで有料の「Standard」が選択されていると思いますが、ここを「Free」に変えて無料プランに切り替えます(Standard のままだと課金対象になります)。そしてリソースグループ、データセンターの場所を指定します(以下の例ではリソースグループは default、場所は Asia Pacific の Sydney を選択しました)。また(ワーカーノードは1つですが)クラスタの名前を指定します(以下の例では mycluster としています)。 ここまで指定して画面右上の Total が Free (無料)になっていることを確認し、「Create cluster」ボタンをクリックして Kubernetes クラスタを作成します:
2019041104


すると Kubernetes クラスタの画面に切り替わります。切り替わった直後のステータスは "Registered" となっていますが、登録作業が進み準備が完了すると "Normal" に切り替わるので、それまでしばらく待つ必要があります。またこの無料 Kubernetes クラスタは1ヶ月間限定で利用できます。1ヶ月後に expire される旨が表示されている点も確認してください:
2019041105


ステータスが "Normal" に変わるとこのようになります。これで Kubernetes クラスタが稼働している状態になりました:
2019041107


"Worker Nodes" タブに切り替えた画面です。このプランではワーカーノードは1つだけしか使えませんが、その1つのワーカーノードが正しく動いていることを確認します:
2019041108


とりあえず、スタンダードアカウントを使って無料の Kubernetes サービスを有効にして、1ワーカーノードのクラスタが利用できるようになりました。



 

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


小型コンピュータのラズベリーパイ、一般的には Raspbian OS で使われることが多いと思っています(自分も特別な理由がなければ Raspbian OS か、または Raspbian の派生 OS で使います)。

が、Raspbian OS って 32bit OS なんですよね。ラズベリーパイ自体は 64bit CPU である arm64 を搭載していることを考えると、「せっかくなので 64bit で使いたい」ともなるわけです。

ラズベリーパイ上で動く 64bit OS はいくつかあるようです。ただリストを見ると「64bit 機能の一部が動かない」という注釈もあったりして、全てが期待通りの挙動をするかというと、そうでもなさそう・・・

というわけで、ラズベリーパイに 64bit Linux である openSUSE を導入する方法を紹介します。といっても導入だけなら Raspbian OS と特別に違うことはなく、どこからイメージをダウンロードするか、程度の違いですけどね。


ラズベリーパイ向けの openSUSE イメージをダウンロードするには、SuSE のラズベリーパイ用ページを参照します:
2019040202


下にスクロールすると、ダウンロードイメージへのリンクが現れます。いくつか種類がありますが、Tumbleweed(開発版)か Leap(安定版)を選び、デスクトップの種類を選択してイメージをダウンロードします。ちなみに僕は Tumbleweed の E20 image を選びました:
2019040201


後は Raspbian OS と同様でダウンロードしたイメージを展開し、(DDWin などのツールを使って)MicroSD カードに書き込み、そのカードをラズベリーパイに差し込んで起動します。

デフォルトのままであれば ID: root, PW: linux でログインできます:
shot-2019-04-02_23-08-13




Swagger APIはインタラクティブに動く REST API のドキュメントを比較的簡単に作ることができて便利です。自分も実際に業務やプライベートアプリに使っています。

この機能を使う場合、YAML と言われるフォーマットをベースにした記述方法で API の仕様を記述するだけで動く API ドキュメントページを作ることができます。

で、この YAML で仕様を記述する際に「コメント」を記述したくなることがあります。実質的にプログラミングする必要なく API テストページを作れるのは便利で、プログラミング時と同様にコメントを残したくなることもあると思います。 が、YAML でコメントを書いたことがなかったので、改めて明示的にコメントを残そうとした際の手法がわからず、調べてみました。

答えとしては「# から行末までがコメント」となるようです。つまり一行単位でコメントが生成されます。「ここからここまで」という範囲コメントは存在していないようです。
info:
  description: 普通の行
#  description: コメント行
  titie: タイトル   # ここはコメント  

なお、コメント扱いにしたくない # を含めたい場合は \# のようにバックスラッシュでエスケープすることで実現できます。




 

このページのトップヘ