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

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

タグ:cf

社内ネットワークに Proxy サーバーが設置されている環境は珍しくないと思いますが、そのような環境下でパブリッククラウドを利用して開発作業を行ったり、アプリケーションをデプロイする際に Proxy 環境に応じた設定が必要になります(ついでにいうと、そのような環境下では特定ポート以外を通さない設定になっていることも多いので、単なる Proxy 対応だけでは不十分なこともあります)。

実際にそのような環境でのお客様対応を通じて苦労した得た情報を設定手順含めて共有します。なお以下は IBM Cloud を使ったケースとして紹介していますが、そこそこ広くパブリッククラウド利用時に役立つ情報だと思っています。


【Proxy 環境下で git コマンドを使う】
コマンドプロンプトやターミナルを開いて以下を入力します:
$ git config --global http.proxy http://my.proxyserver.com:8080

$ git config --global https.proxy http://my.proxyserver.com:8080


なお http://my.proxyserver.com:8080 部分は Proxy サーバー名およびポート番号です(以下も同様)。


【ssh でなく https で github(gitlab) を使う】
これは Proxy とは直接関係ないのですが、ssh プロトコル通信が閉じられているような環境下でプライベートな github(gitlab) リポジトリを使いたい場合の、つまり https プロトコルでプライベートな github(gitlab) リポジトリを使う場合に必要な設定項目です。 作業内容としては Private Access Token を設定することで https でも認証が可能になり、プライベートリポジトリを利用することができるようになります。以下 github を使う前提での画面で紹介しますが、gitlab でもほぼ同様です。

まず github にログインし、画面右上の "Settings"  を選択します:
2020022801


次に画面左の "Developer Settings" を選択します:
2020022802


Developer Settings のメニューから "Personal access tokens" を選択し、画面右の "Generate new token" ボタンをクリックします:
2020022803


新たに生成するトークンの設定を指定します。まず名前を(myToken など)適当に入力し、scopes を選択します(わからなければとりあえずは全部):
2020022804


そして最後に画面下部にある "Generate token" ボタンをクリック:
2020022805


すると以下のような画面になり、トークン文字列が表示されます。この文字列はこの一回しか表示されません(一度異なるページを表示した後に再度表示する方法は用意されていません)。別ファイルにコピーするなどしてこの値を再度入力できるようにしてください:
2020022806

ここまで完了していれば、以下のコマンドで https プロトコルだけで github から git clone ができます:
$ git clone https://github.com/aabbcc/xxyyzz.git
 Username: (GitHub のユーザー名)
 Password: (取得したトークン文字列)

なお gitlab の場合は以下のようになります:
$ git clone https://gitlab.com/aabbcc/xxyyzz.git
 Username: oauth2
 Password: (取得したトークン文字列)

【Proxy 環境下で npm コマンドを使う】
サーバーサイド JavaScript である Node.js を使ってアプリケーションを開発する場合、ほぼ npm コマンドを併用することになると思っています。この npm コマンドを Proxy 環境下で使う場合にも設定が必要です。
$ npm -g config set proxy "http://my.proxyserver.com:8080/"
$ npm -g config set https-proxy "http://my.proxyserver.com:8080/"
$ npm -g config set registry "http://registry.npmjs.org/"

proxy と https-proxy の設定をすれば動くはず、ですが、この2つだけではエラーになることがあるらしいです。その場合は registry も設定してください。


【Proxy 環境下で cf コマンドを使う】
これは IBM Cloud 環境に特化した設定かもしれませんが、PaaS である Cloud Foundry ランタイムにアプリケーションを push(デプロイ)する際に利用する cf コマンド(ibmcloud cf コマンド)も Proxy 環境下ではそのための環境設定をしないと使うことはできません。

※Delivery Pipeline サービスを利用することで、cf コマンドを使わずに Git と連動してデプロイすることは可能です。


具体的には環境変数の設定を行う必要があります。以下は Windows 10 での環境変数設定方法です。

コントロールパネル - システムとセキュリティ - システム - システムの詳細設定 を選択します:
2020022807


「詳細設定」タブの「環境変数」ボタンをクリック:
2020022808


ユーザー環境変数で「新規」ボタンをクリック:
2020022809


新しいユーザー変数として、以下の2つを設定します:
変数名変数値
http_proxyProxy サーバー URL
https_proxyProxy サーバー URL

20200228010


2つの環境変数が新たに追加されていることを確認します:

20200228011


これで cf コマンドを指定した Proxy サーバー経由で実行することができるようになりました。

自分はラズパイ(Raspberry Pi 3B)をリモートの開発環境として使っています。自宅内ネットワークで常時起動させ、OpenVPN 経由で外からもアクセスできるようにしています。その辺りの設定についてはこちらを参照してください:
OpenVPN でローカル(自宅)ネットワークに VPN 接続する


そんなラズパイに各種開発環境やら docker やら TensorFlow やら、、を導入しています。これで外からも利用できる開発環境を構築しています:
http://dotnsf.blog.jp/tag/raspberrypi


さて、コーディングして動かすところまではこういったツールだけで問題ないのですが、1点だけ不便に感じる点がありました。それが「cf ツール」です。作ったアプリケーションを IBM Bluemix (Cloud Foundry) 環境上にデプロイする際に使うツールなのですが、公式にはラズパイ用のバイナリは提供されていません。なのでラズパイで開発して、動かして、テスト&デバッグして、、というところまではこの環境でできるのですが、作ったアプリを IBM Bluemix 上で動かす、という最後のステップの際に別の(cf ツールの導入された)環境に切り替えて行う、というちと面倒な手順をとる必要がありました:
Releases cloudfoundry/cli

2017080601


これをラズパイ環境のままで行えるようにする、というのが今回の目的です。実はこれまでにも IBM LinuxONE 環境などで同様の経験はしていて、その時は自分でソースからビルドして対応したりしていました:
IBM LinuxONE コミュニティクラウド上で cf コマンドを動かす

2017080602
(↑メインフレーム上で cf を動かしたのは、もしかすると世界中で自分だけかも・・)


で、同様の問題がラズパイで発生しているということです。というわけで、ラズパイ環境でも同様に cf ツールをビルドしてみました。以下はその手順紹介ですが、基本的には上記の LinuxONE 環境と同じことをしています。

まず cf ツールは go 言語で書かれているため、ビルドには go 言語が必要です。ラズパイ用の go 言語導入については以下を参照して、go 言語が動く環境を作っておいてください:
ラズパイに go 1.8 をインストールする

go 言語が動くようになったら次はソースコードの入手です。以下のコマンドを実行します:
$ go get code.cloudfoundry.org/cli

これで $GOPATH/src/code.cloudfoundry.org/cli 以下にソースコードが展開されます。これをビルドします:
$ cd $GOPATH/src/code.cloudfoundry.org/cli
$ bin/build

ビルドが成功すると $GOPATH/src/code.cloudfoundry.org/cli/out/ 以下に cf コマンドが生成されます。試しに動くかテストしてみます:
$ cd $GOPATH/src/code.cloudfoundry.org/cli/out
$ ./cf -v
cf version 6.29.0+35e54cd.2017-08-06

バージョン番号が表示され、ちゃんと動くことが確認できました。後はこのコマンドを PATH の通った所に移動すれば完成です。
$ sudo mv $GOPATH/src/code.cloudfoundry.org/cli/out/cf /usr/local/bin
$ sudo chown root.staff /usr/local/bin/cf


なお、このラズパイ版の cf コマンドについては困っていた方が他にもいたようで、たまに有志でビルドされたものが見つかります。僕が動作確認しているわけではないし、動作保証もできないのですが、こういった所から入手して使うという手段もありそうです:

https://github.com/mmb/cf-cli-pi
https://cf-cli-pi.s3.amazonaws.com/index.html


前2回の続きです:
IBM Bluemix にカスタムサービスを追加する(1/3)
IBM Bluemix にカスタムサービスを追加する(2/3)


前回作成した REST API を実際に IBM Bluemix のカスタムサービスとして登録し、利用するまで(正確には使用を終えてカスタムサービスから削除するところまで)の手順を紹介します。なおこの手順はコマンドラインツールである cf が必要になるので、インストールしていない場合は各自の環境にあった cf をあらかじめダウンロード&インストールしておいてください:
https://github.com/cloudfoundry/cli/releases


また、今回カスタムサービスとして登録する REST API は前回紹介した app.js が https://dotnsf-operation.mybluemix.net/ にデプロイされて動いているものとします。以下の説明でのこのホスト名部分を実際にみなさんがデプロイしたホスト名に合わせて読み替えてください:
2017021401

2017021401


まず最初に、以下で登録するカスタムサービスをバインドして動作確認するためのランタイムを用意しておきます。動作確認用のアプリケーション(後述)を PHP で用意したので、IBM Bluemix 上に PHP のランタイムを1つ作成します(以下の例では teyande-php-env という名前で作成しています)、なおこの段階ではサービスは何もバインドしないでください:
2017021402


このランタイムに以下の内容の PHP アプリケーションをプッシュします:
https://github.com/dotnsf/phpEnv


上記アプリケーション(index.php)はシンプルに「ランタイムサーバー上の全環境変数とその値を表示する」というアプリケーションです。プッシュ後にサーバーにアクセスすると以下のような画面になります。この時点ではサービスを1つもバインドしていないので、環境変数 VCAP_SERVICES の値は空オブジェクトを示す "{}" となっていることが確認できるはずです:
2017021403


ここまでで準備は完了です。では前回紹介したサービスを IBM Bluemix のカスタムサービスとして登録した上でインスタンス化し、このランタイムにバインドした上で、この環境変数がどのように変わるかを確認してみます。

コマンドプロンプトかターミナルを起動し、上記の PHP ランタイムと同じデータセンター(この場合は US-SOUTH)の自分の組織に cf コマンドでログインします:
2017021404


カスタムサービスを利用するにためには Cloud Foundry の「サービスブローカー」(カスタムカタログのように理解してください)に登録しておく必要があります。まず現在のサービスブローカー一覧を確認するため "cf service-brokers" コマンドを実行して、この時点では何も登録されていないことを確認します:
2017021301
 ↑"No service brokers found"(何も登録されていません)です


ではサービスブローカーを新規に1つ作成します。以下のパラメータを付けてコマンドを実行します:
> cf create-service-broker サービスブローカー名 認証ユーザー名 認証パスワード サービスの基本URL --space-scoped
2017021302


今回、サービスブローカー名は "dotnsf-operation" とします。認証のユーザー名とパスワードは dotnsf-operation の Catalog API などが実行される時用に指定した auth_user / auth_pass の値を指定します(詳しくは前回の記事参照)。サービスの基本 URL は今回 "https://dotnsf-operation.mybluemix.net" です。そして最後にオプションの "--space-scoped"(同一組織内のユーザーが使えるサービスとするための指定)を加えています。

コマンドが成功したことを確認し、再度 "cf service-brokers" を実行してみます。先程は結果に何も含まれていませんでしたが、今度は直前に作成したばかりの "dotnsf-operation" サービスブローカーが、指定した URL で登録されていることを確認してください:
2017021303


これで dotnsf-operation API がカスタムカタログに登録された状態になりました。ただ IBM Bluemix のウェブ UI ではカスタムカタログを表示する画面が存在していないので、この時点ではまだウェブ UI には現れませんが、cf からは同様にインスタンスを作成することができるようになっています。

というわけで、続けて cf でこのサービスをインスタンス化してみます:
> cf create-service サービスブローカー名 プラン名 サービス名

サービスブローカー名は dotnsf-operation の Catalog API(GET /v2/catalog) 内で定義したもの(今回の場合は dotnsf-operation-service)を指定します。プランも同様に Catalog API 内で定義したもの(今回は "free" と "enterprise" の2つ)の中から指定できますが、今回は "free" を指定しています。最後に IBM Bluemix 内でのサービス名として "dotnsf-operation-1" と指定しています:
2017021304


ここまでの手続きが完了すると、dotnsf-operation サービスがインスタンス化され、ウェブ UI の利用中サービス一覧の中にも表示されるようになります:
2017021301


この時点でサービスを選択し、管理タブを開くと Dashboard API で定義した内容が表示されるはずです(https で Dashboard API にアクセスできることが条件です):
2017021000


ではこのサービスを最初に作成した PHP ランタイムにバインドしてみましょう。PHP ランタイムの画面に移動し、接続タブの「既存に接続」をクリックします:
2017021302


現在利用中のサービスインスタンスの一覧が表示されます。その中に "dotnsf-operation-1" という名前のサービスが含まれているはずなので、これを選択して「接続」をクリックします。そしてこの内容をランタイムの環境変数にも反映させるため「再ステージング」します:
2017021303


改めて同ランタイムの接続タブを参照すると、"dotnsf-operation-1" サービスが追加されていることを確認できます。ここで「資格情報の表示」をクリックします:
2017021304


今回の dotnsf-service の Bind API では credentials 情報として uri だけを追加していました。そのためこのサービスインスタンスの資格情報にも uri 1つだけが credentials 情報として表示されていることが確認できるはずです:
2017021305


改めてランタイムのトップ画面にアクセス(リロード)します。今回は先程と異なり dotnsf-operation-1 サービスがバインドされているので、環境変数 VCAP_SERVICES は空オブジェクトではなく、dotnsf-operation-1 の情報が表示されているはずです。credentials 情報も先程確認したものと同じものが表示されています:
2017021306



・・・というわけで、IBM Bluemix のカスタムサービスを作成して、登録して、インスタンス化して、ランタイムとバインドして環境変数に反映させる、という一連の作業ができることを確認できました!

最後に使い終わったサービスブローカーを削除する手順を紹介しておきます。まず(同サービスブローカーを使っているランタイムからのバインドを全て解除した上で)サービス一覧画面からインスタンス化されたサービスを削除します:
2017021305


サービスが削除されるとウェブ UI からは見えなくなります。が、まだサービスブローカーには登録されているので、以下の cf コマンドでサービスブローカーからも削除します:
> cf delete-service-broker サービスブローカー名
2017021306


このコマンドが成功すると、サービスブローカー一覧からも削除されます。念のため "cf service-brokers" コマンドで確認します:
2017021307




久しぶりの超大作ブログとなり、3回に分けて紹介しましたが、IBM Bluemix のカスタムサービスを作るために実装しないといけない内容や、実装後の登録方法などを紹介できたつもりです。自分が作った REST API を IBM Bluemix に統合して使いたい場合や、公式なサードパーティ API としての登録を検討する場合に必要となる実装がどんなものかを説明しました。

今回紹介した内容はあくまで「同一組織内でのみ有効なカスタムサービス」の登録方法および手順の紹介でしたが、全 IBM Bluemix ユーザー向けに実装する場合であっても同様の API 実装は必要になります。そういったエコシステムを活性化する上での役立つ情報になれば幸いです。


(参考)
 https://www.ibm.com/blogs/bluemix/2017/01/extend-bluemix-service-broker/

IBM LinuxONE(メインフレーム版 Linux)挑戦シリーズ。今回は IBM Bluemix でも使う cf コマンドラインツールの導入に挑戦します:
2017012000


cf ツールは IBM のクラウド環境である IBM Bluemix や、同製品がベースとしているオープンソース PaaS 環境である CloudFoundry をコマンドラインから操作するためのツールです。手元で作成したソースコードやアプリケーションファイル一式を Bluemix/CloudFoundry のランタイムにデプロイする時などに使うコマンドラインアプリケーションで、これがあれば Bluemix や CloudFoundry の管理操作が可能になるものです。主なプラットフォーム(Windows, Linux, MacOS)向けのツールはこちらから最新版の実行バイナリがダウンロードできるようになっています:
https://github.com/cloudfoundry/cli/releases

2017012001


ここでバイナリが提供されている Linux は x86(_64) アーキテクチャの Linux です。他の Linux に関しては公式からは提供されていませんが、パッケージマネージャーから簡単に導入できるようになっているものもあったりします(例:ラズベリーパイの RaspbianOS)。

残念ながら s390x(IBM LinuxONE)プラットフォーム向けのバイナリは提供されていない模様です。ただ cf ツール自体もオープンソース製品なので、ソースを入手して自分でビルドできる可能性もあります。というわけで挑戦してみた様子を以下に紹介します。 前提として IBM LinuxONE は IBM LinuxONE コミュニティクラウド上に RHEL 6.x で用意しているものとします(1インスタンスが最大 120 日間無料で利用できます):
IBM LinuxONE コミュニティクラウドを使う(2017年1月版)


またオープンソースツールである cf コマンドは、Go 言語で記述されています。というわけでビルドには Go 言語の環境が必要になります。IBM LinuxONE で Go 言語を使えるようにするための手順は以下を参照ください(最後の環境変数 GOPATH と PATH の設定までを行う必要があります):
IBM LinuxONE コミュニティクラウド上で Go 言語を動かす


早速ソースコードを入手してビルドを、、、の前に1つ準備が必要です。ドキュメントにかかれている手順を IBM LinuxONE 環境でそのまま実行しても途中でエラーになってしまいました。試行錯誤の結果、これを回避するために事前にパスの通ったディレクトリに "s390x-linux-gnu-gcc" という名前で gcc が使えるようにしておく必要がありそうでした。というわけで(この例では /usr/local/bin/ 以下に)シンボリックシンクを作っておきます:
# ln -s /usr/bin/gcc /usr/local/bin/s390x-linux-gnu-gcc

改めて、まずはソースコードを入手しましょう。go コマンドを使って以下のコマンドを実行します:
# go get code.cloudfoundry.org/cli

コマンドが成功すると、$GOPATH/src/code.cloudfoundry.org/cli 以下に cf ツールのソースコードが展開されます。このディレクトリに移動して bin/build コマンドを実行してビルドします:
# cd $GOPATH/src/code.cloudfoundry.org/cli
# bin/build

ビルドが成功すると、cf コマンドが $GOPATH/src/code.cloudfoundry.org/cli/out/ 以下に作成されます。このコマンドにパスを通すか、パスの通ったディレクトリ(以下の例では /usr/local/bin)以下にシンボリックリンクを張って実行できるようにすれば準備完了です:
# ln -s /usr/local/go/src/code.cloudfoundry.org/cli/out/cf /usr/local/bin/cf

これで cf ツールがコマンドラインから実行できるようになりました(青字は出力結果):
# cf -v
cf version 6.23.1+d752ec1.2017-01-19


LinuxONE については、自分も最初は「メインフレーム上の Linux で、普段使っているプログラミング言語やツール、サーバー類がどこまで使えるんだろう?」と半信半疑だったのですが、いざ使ってみると x86_64 アーキテクチャと比べてもほとんど変わらずに使えるということが分かってきました。事実 cf ツールが動くと分かった今、IBM Bluemix の、オープンソース系のアプリケーション開発やテストをこれ単体で行えるだけの環境はほぼ揃っているように感じます。


なお、今回紹介した手順は(基本的には)以下のドキュメントを参考にしています:
https://github.com/cloudfoundry/cli/blob/master/.github/CONTRIBUTING.md

 

IBM Bluemix のアプリケーションベースの1つが Cloud Foundry です。オープンソース版の PaaS 環境でもある Cloud Foundry を拡張したものが IBM Bluemix ですが、この Cloud Foundry が利用するコンテナ技術に新しいテクノロジーが加わりました。それが Diego です:
https://docs.cloudfoundry.org/concepts/diego/diego-architecture.html

2016120700


これまでの Cloud Foundry では DEA(Droplet Execution Agent) というコンテナ技術を使っていました。この進化版としての、新しいコンテナフォーマットや SSH ログインをサポートした新しいコンテナ、それが Diego です。DEA と Diego の技術的な相違点など、詳細はこちらをご覧ください:
https://docs.cloudfoundry.org/concepts/diego/dea-vs-diego.html


さて、この Diego は先日 IBM Bluemix でも有効になりました。現状は DEA と Diego が両方サポートされている状態で、デフォルトは DEA になっています。またこれまでに Bluemix 上で作成して動いていた CloudFoundry ランタイム(以下、 "CF ランタイム")アプリケーションは DEA コンテナのまま実行されています。なので、以下に紹介するような特別なことをしなければ特に何も変わらずに動いている/動く、ということになります。


一方、Diego コンテナでは DEA ではできなかったいくつかの新しい機能が有効になっています。その1つが ssh によるリモートログインです。というわけで、Bluemix アプリケーションを Diego コンテナに切り替えて、ssh ログインができることを確認する手順を以下に紹介します。


まず、現状で Diego コンテナを利用するには cf コマンドラインツールを利用する必要があります。また Diego コンテナを使う場合、cf ツールのバージョンは 6.13.0 以上である必要があります。なお cf ツールのバージョンを確認するには "cf -v" と実行してください:
$ cf -v
cf version 6.22.2+a95e24c-2016-10-27

cf コマンドを使ったことがなかったり、古い cf コマンドを使っている Bluemix ユーザーは、まずは自分の環境にあった cf ツールを GitHub からダウンロードしてインストールしておいてください:
https://github.com/cloudfoundry/cli/releases


次に Diego 機能を使うために cf コマンドに Diego-Enabler プラグインをインストールします。これは以下のコマンドでインストールできます:
$ cf add-plugin-repo CF-Community https://plugins.cloudfoundry.org/
$ cf install-plugin Diego-Enabler -r CF-Community

これで Diego-Enabler が使える cf コマンドが用意できました。では実際に Bluemix 上の CF ランタイムアプリケーションを Diego コンテナに移行してみましょう。

今回、サンプルとして "dotnsf-diego-java" という名前の CF アプリケーションを Liberty for Java ビルドパックで作成しました。以下、この名前を使ってコマンドを実行する様子を紹介しますので、みなさんのアプリケーションの名前に置き換えてお読みください。なお、この時点では(これまで通り)DEA コンテナ上で動いているアプリケーションです:
2016120701


ためしにブラウザからアクセスすると、デフォルトの "Hello World!" が表示されます:
2016120702


このランタイムを Diego コンテナ上に移行してみましょう。まずは cf ツールでログインを行います:
$ cf login -a https://api.ng.bluemix.net/ -u (ユーザーID)
API エンドポイント: https://api.ng.bluemix.net/

Password> (パスワードを入力)
※↑の例では USA データセンターにログインしています。他のデータセンターの場合は "ng" の部分をデータセンターに合わせて変更してください。

最初に対象のランタイムアプリケーションを停止させる必要があります:
$ cf stop dotnsf-diego-java

停止が確認できたら、このランタイムのコンテナを Diego に変更します:
$ cf enable-diego dotnsf-diego-java

そして再スタートです:
$ cf start dotnsf-diego-java
  :
  :
要求された状態: started
インスタンス: 1/1
使用: 512M x 1 インスタンス
URL: dotnsf-diego-java.mybluemix.net
最終アップロード日時: Wed Dec 7 01:51:43 UTC 2016
スタック: cflinuxfs2
ビルドパック: Liberty for Java(TM) (WAR, liberty-16.0.1_3, buildpack-v3.5-20161114-1152, ibmjdk-1.8.0_20161019, env)

     状態   開始日時                 CPU      メモリー            ディスク           詳細
#0   実行   2016-12-07 11:05:40 AM   181.1%   512M の中の 97.9M   1G の中の 189.8M

この時点でアプリケーションは Diego コンテナ上で動いています。ただアプリケーションそのものには何の変更も加えていないので、見た目は変わっていません:
2016120702


ではこの Diego コンテナに SSH でログインして、アプリケーションを直接書き換えてみましょう。SSH でログインするには以下のコマンドを実行します:
$ cf ssh dotnsf-diego-java
vcap@18ce933a-65ca-4e3f-5f0c-d9fac300d6f9:~$  ←プロンプトが変わった!

ここは既に CF アプリケーションの中です。もちろん使えるコマンドには制約がありますが、例えば top コマンドを使ってサーバーリソースの利用状態を確認することもできます:
2016120703


ではアプリケーションを書き換えてみましょう。Liberty for Java ビルドパックの場合、アプリケーションは app/wlp/usr/servers/defaultServer/apps/myapp.war/ ディレクトリにあるのでここで移動し、vi で index.html を直接編集します:
$ cd app/wlp/usr/servers/defaultServer/apps/myapp.war
$ vi index.html

変更内容はどうでもいいのですが、とりあえず <body> タグの直後に目立つように <h1> タグのメッセージを追加してみました(↓赤枠部分を追加して保存):
2016120704


この状態で(再プッシュとかなしで)同アプリケーションをブラウザでリロードすると、入力したメッセージが画面に表示されて、アプリケーションが書き換わったことが確認できました:
2016120705


CF ランタイムは今までこれができないという制約があったのですが、Diego コンテナに切り替えることで課題を1つ克服できることになりますね。

このページのトップヘ