_・)Keep Smiling

モソモソと日々の雑感を書き溜めるというか書き殴るというか書き捨てるというか

Voice Kitが届いたよ

この記事はRaspberry Pi Advent Calendar 2017 - Adventarの22日目の記事です。 微妙に遅刻ですが気にしないで書きます。

AIY Projectとは

Googleさんが始めた”AI自作プロジェクト”がAIY Projectsです。

aiyprojects.withgoogle.com

サイトを見てもらえばいきなり写真が出てきますが、カードボード型のケースに各種デバイスとRasPiを突っ込んでAI制御できちゃうようなものを自分自身でつくってみないか?って言う感じのプロジェクトですね。

現在はVoice KitVision Kitの2種類が販売されています(Vision Kitは現在予約受付中で12月31日発売予定)が、日本で購入できるのはVoice Kitのみとなります。とは言え、Vision Kitはやってることも画像解析なんで敷居高そう・・・お値段もやや高め・・・。詳しくはEngadgetさんの記事あたりを見て頂くのが良いでしょう。

japanese.engadget.com

Voice Kitの販売について

日本からはまだ注文できないVision Kitと違い、Voice KitはRaspberry Piの販売でもおなじみの各社さんから比較的簡単に日本で購入できます。

他にAmazonでも販売している業者が見つかりますが割高なのでやめておいた方がいいでしょう。

私は、販売発表当初にこりゃ面白そうだなーって思って、いつものとおりPimoroniで注文しました。こんなにあっさり日本で買えるようになるならもう少し待ってても良かったかなーと思ったり思わなかったり・・・。

ちなみに、このKitにはRaspberry Piは含まれておりません。MicroSDカードやUSB電源などと合わせてKSYさんやスイッチサイエンスさんから購入するのが良いでしょう。

で、Voice Kitで何ができるの?

そもそもアドカレに登録下地店では、Voice Kitの組み立てや出来ることの紹介をするつもりだったんですが、時感が過ぎる中で結構きっちり紹介しているBlogがいくつも出てきたのでぶっちゃけ私が書く必要はないなー・・・とか思っちゃっています・・・。

まぁ簡単に言えば「自家製Google Homeが作れる!(かも)」という感じですね。

Voice Kitは酷く乱暴に言うとマイクとスピーカーとやや大きめのボタンがRasPiにくっついたよーってなキットで、音声認識についてはInternetを経由してGoogle Cloud Platform上のAPIを利用しにいきます。本当にこれだけだったら日本語もサクサクつかえてお値段的にも安いGoogle Home miniあたりを買うのがお勧めなんです。

しかしVoice Kitの場合はRaspberry PiのGPIOを有効活用することが出来てしまいます。現在日本で市販されている各種AIスピーカーのホームコントロールが電球とか赤外線コントロールくらいしか対応していないのに対して、Voice Kitでは音声でサーボモータを制御できちゃったり、モーターを駆動させちゃったりできる訳です。レッドスネークカモーンで蛇を出すのなんてお茶のこさいさいなわけですよ(ネタも表現も古い)。

ただし、注意点もけっして少なくありません。例えば・・・

  • Google Cloud Platformにアカウントの登録が必須である
  • 各種APIの仕様や使い方を学ぶ必要がある
  • デモスクリプトでも使用するGoogle Assistant APIは日本語対応していない
  • APIの種類によっては使用量に応じた課金が生じることがある

などなど−・・・ですね。

特に最初はプログラミングやGoogle CloudのAPI利用に関して慣れていない方だと、基本的に英語での音声コマンド利用となると思います。Google Homeのように便利になんでも日本語音声で・・・という為のものではないということは理解しておいた方が良いでしょう(決して日本語での音声コマンドが使えないというわけではありません)。

この記事を読め

完全に他人の褌で相撲を取る感じですが、Voice Kitの良記事を書かれているBlogなんかを紹介したいと思います。同じようなこと重複して書いてもあまり意味ないですしね・・・。

まず最初はクレウエタンさんの一連の記事。Voice Kitの到着から組み立て、そして起動から日本語での音声コマンドによる制御まで一通りの作業を苦労した話も交えて面白く紹介してくれています。

kureuetan.com

お次はAzuritonさんの一連の記事。こちらも複数の記事で丁寧に組み立てからGCPへの登録などの作業を紹介されています。クレウエタンさんの記事も失敗談とか感想とか多めで読み物として好きなんですけど、Azuritonさんのは実用性が高くて読みやすい感じがしますね。

azriton.github.io

最後は販売もしているスイッチサイエンスさんの記事。こちらは1つの記事の中で簡潔に紹介しているので手軽に読むことができます。こんな感じなんだなーっていうのを掴むのにはいいと思います。

mag.switch-science.com

まだまだ他にも見つかるので、ググりつつ探してみるのが吉かと思いますです。

私の場合

んで、せっかくなので私の感想なんてものも。

実はAIスピーカーに関してはこのVoice Kitが初めてでした(その後、招待によりAmazon Echoはゲットしてます)。

AIY Projectで配布している標準OSイメージについているデモスクリプトだけでもアレコレあそべて楽しかったですが、やっぱり英語音声コマンドでもGoogle Homeなんかと比べると出来ることも少ない(もしくはどうすればいいか分からない)ってのが多くて戸惑いました。

一番ネックだったのは、私の工作って基本深夜に一人ひっそりといつもやってるので家族の寝静まった家の中では音声で遊ぶのが非常に難易度が高いという点でした。自分の声だけでもウルサい!って言われそうなんですけどそれにスピーカーの音声も加わりますしね・・・。まぁ、ボリューム調整したりなんなら出力をイヤホンにしたらいいのかもしれないですけど、それもねぇ。。。?

とはいえ、このまま活用できないのももったいないので、年末年始のお休みを利用して何か音声で遊べるものを考えたいと思います(作るとは言ってない)。本当は音声でEjectコマンドを実行してウィーンする・・・なんても考えていたんですが・・・うう。

_・).。oO(音声制御のタンクとかならいけるかもしれない?)

ちなみに、私の拙い英語で話しかけても結構認識してくれるのは嬉しかったです。(英語版の)Siriさんが出始めた頃はさっぱり認識してくれなくて途方に暮れましたからね・・・。

まとめ

てなわけでなんか中途半端な報告日記みたいになってしまいましたがAIY ProjectのVoice Kit紹介でした。まだまだ(言語的な)制約もありますが、いずれGCPAPIも日本語対応がもっと進んでくれると信じていますので、これからが楽しみなKitなのではないでしょうか。音声制御できる変態的面白い工作がドンドンでてきてくれると良いですね。

Rancher JPの運営メンバーとして便利だなーと思ったツールの話

この記事は勉強会運営 Advent Calendar 2017の17日目の記事です。

adventar.org

Rancher JPを知っていますか?

Rancherというオープンソースソフトウェアがあります。ざっくり言うと(Docker)コンテナを管理する為の基盤を構築したりしてくれる素敵OSSなんですが、そのRancherの普及を目的として日々活動している日本のRancherコミュニティがRancher JPです。

2017年はこのRancher JPのAdminメンバー(通称:Cowboys、俗称:牛勢)として、毎月1回以上の頻度で開催されるMeetupの運営などを行って参りました。その中で「お、このツールはみんなで作業するのに中々いいね」と思うものがあったのでご紹介します。

共同編集ドキュメントツール:hackMD

複数の人が同時にドキュメントを編集するというケースが最近はかなり多くなってきた気がします。ちまちまWordだのExcelのファイルを共有フォルダで順番に編集していくのは今やはっきりって時代遅れ・・・というのは既に皆様にも共通の感覚としてお持ちなんじゃないかなーと思います。

実施、GoogleドキュメントOfficeオンラインをはじめ、OSSEtherpadなど、複数人で同時編集をするためのサービスやツールがかなり出そろってきている感じがします。

そんななかで今年使い始めて中々良い感じだったのがHackMDです。

hackmd.io

RancherJPの場合、Meetupの開催毎にほぼ欠かさずAdminチームでミーティングを開催します。しかし、皆さんボランティアでやっている活動なので、なかなか同じ場所に集まってミーティングが出来ないことも少なくありません。そうした場合は、WebExなどのオンラインミーティングを行うのですが、そこでHackMDがかなり強力なツールとして役立っています。

共同編集できるツールという時点でも便利なのですが、さらにMarkdown対応というのが大変ちょうど良いです。

例えばOfficeオンラインでWordをつかった場合、Fontだの文字装飾だのを気にしなければいけなくなることがあります。例えば、業務でOneNoteを使って同僚と情報共有をすることがたまにあるのですが、結構フォントの種類やサイズなどが勝手に補正されたりしてイライラすることがあります。特に共同編集者があまりそのへんを気にしない相手だと余計にイライラが募るわけです・・・。

Markdownの場合はそうした煩わしさはほぼ考えなくてもいいのが嬉しいですね。Markdownを覚える必要はあるものの、ほぼ直感的に使えますし、そもそも難しい書式もあまり必要ありません。誰でも使えると言ってしまって問題はないでしょう。

話を戻してRancher JPおいては、事前ミーティングの議事録として、またそれがそのままMeetup開催時のメモとして、メンバー間の情報共有に役立っています。

チャットツール

これはなんとも言えない部分もあるんですが、Slackで当初行っていたAdminメンバーのチャットは現在別のものに移行しています。特に秘密にしたいという訳ではないのですが、ツールの名前は敢えて言いません。というのも、そのツールが最高として使い始めたというよりはなんとなく流れでそうなったという感じだからです・・・。

ちなみにSlackから移行したのも大きな理由があるというよりは、Meetupの際の発表者などを呼んだりしていたら、やっぱり運営は別にしよう・・・みたいな流れから別にできた感じです。別にSlackでもLINEでもHangoutでもTelegramでも、メンバー間でうまくコミュニケーションがとれるのであれば何でもいいと思います。とはいえ、やっぱり何かしらこうしたツールは必要ですね。

逆にメール(メーリングリスト)はRancher JPではほぼ使いません。メールは時代遅れだよね、というつもりはありませんが、やはりリアルタイム性に乏しく、見逃したりする危険性もありますので、あまりむいていませんね。ちゃんと会話の履歴が残るチャットツールがあれば十分だと感じています。メール怠いし・・・。

タスク管理

いわゆるカンバン方式なタスク管理ツールは業務での活用されている方も多いのではないでしょうか。

このへんはTrelloが有名でしょうか。 trello.com

ぶっちゃツールそのものはなんでも良いとは思うんですが、Rancher JPはmeistertaskを使っています。

www.meistertask.com

デザインに遊び心が感じられる分、meistertaskのが好きではありますが、ぶっちゃけなんでもいいとは思います。

Rancher JPのようにMeetupやハンズオン、もくもく会、さらにはOSCなどのイベント出店などを毎月のように沢山やっているとついつい準備しなければいけないことがヌケてしまうこともあるので、転ばぬ先の杖としてタスク管理をきちんとやっていくのは大切だなーと感じています。

ただ、実際には一部のメンバーがこまめにタスク管理をしてくれている状態で、全員がきちんとタスクを意識できているとは言えないかなーという感じです。私もそんなにきっちりタスク管理する性格でもないので・・・。いつも他のメンバーには悪いなーと思いつつ、たまにタスクを眺めてます。

Googleさんのいろいろ

このへんは別に何も特別ではないですが、パンフレットとかのデータもあるので一応ファイル置き場としてGoogleドライブなどを活用しています。また、Meetupで必ず参加者と記念撮影をするので、そのあたりのデータもGoogleフォトに貯めてあったりします。このへんは他のコミュニティでも似たようなものかなー?とも思いますが、やっぱり便利ですね。あ、カレンダーでイベント日程なんかも管理してますよ〜。

イベント管理:Connpass

最近はRancher JPのWebよりも活発に更新されていそうなRancher JPのConnpassページ

rancherjp.connpass.com

基本的にTokyo開催のものだけではなく、他の地方開催のMeetupなども含めて情報はConnpassで公開し参加者を募集しています。

毎回、申し込み人数などの反応に一喜一憂したりキャンセル率の動向にハラハラしたりしていますが、無料でこのような運営が出来るツールなのでありがたいなーと思っています。

個人的にはatndとかも使っていたんですが、他のサービスが方針転換したり有償化したりしている中で、なるべくConnpassさんはこのまま頑張って欲しいですね・・・。

動画配信

一部のイベントを除き、Rancher JPのMeetupの様子はcrash.academyで撮影/配信をお願いしています。

crash.academy

会員登録は必要とはなりますが無料で動画を確認できますので、参加出来なかった方にも発表内容などを後日市長して頂くことが可能になっています。 動画配信なども興味はなくもないんですが、やっぱり機材に回線にと敷居が高く、今は後日動画配信という流れをとっています。

とは言え、無料でこのような配信をサポートして頂いているのは正直ありがたいなぁーと思っています。毎回機材持ち込み&数人体制の撮影隊が来ますしね・・・ありがたや。

まとめ

そんなわけでRancher JPで普段使っているツールやらお世話になっているサービスを紹介してみました。 結局のところ、こうしたものはあくまでも便利な道具でしかないので、重要なのはそれを使う人側がしっかりと連携していくことにあるんですけどね。

2017年はCloud Garageをこんな風に使いました

この記事は#CloudGarage Advent Calendar 2017 - Adventarの16日目の記事です。

安さは正義

2017年はRancher JPのメンバーとして色々なところで発表させてもらいましたが、Rancherの環境をどう持つかが課題でした。

当初は自分のMacBookの中で仮想マシンを何台か動かしたり、社内OpenStack環境でインスタンスをいくつか上げたりもしてみたりはしたんですが、使い勝手の面で課題があり、できればもう少し恒常的に置いておきやすい場所がほしいなーと思っていました。

ベアメタルクラウドであるPacketがRancherOSに対応していたり価格が(比較的)安かったりしたので使ってはいたんですが、複数のインスタンスを常時動かしたいとなると、それなりに費用が掛かってしまい、どうしても使うときだけインスタンスを上げる・・・なんて感じになってしまっていました。

そんな折りに、安価複数のインスタンス常時利用できるというCloud Garadeさんのことを知りました。正直、最初は「安かろう悪かろうでしょ?」 とか、「ユーザー数爆発したら激重になるんじゃないの?」とか思っていたんですが(すみません)、おもった以上にストレージが速かったり、契約数を制限して激重にならないような運用をしてたりと、良い意味で想像を裏切られる安心のサービスでした。

とまぁ、こんなわけで2017年後半は、いろいろな検証とかでCloud Garageを使ってきましたが、今日はどんなことで主に使ってきたかを書いておきたいと思います。

Rancher環境としての利用

Cloud Garageさんでインスタンスを作成する際には予め用意されているOSイメージから選択して起動します。一般的な主要Linuxディストリビューションは用意されているんで困らないのですが、そこにRancherOSもラインナップされているというのが牛勢の心を掴みました。

RancherOSを起動させたいときも選択するだけでいいので非常に簡単です。とはいえ、RancherOSの場合はISOイメージをマウントして起動しているだけですので、Diskインストールしたい場合は結局別途作業が発生します・・・。最初はここも少し戸惑いましたが、今はコツも抑えたので非常に簡単です。詳細は、こちらの資料とかを参考にしてみてください。

www.slideshare.net

Rancherの場合、通常は複数のホストをDockerコンテナの配置先として使います。また、Rancher Server(のコンテナの配置先)となるホストとRancher Agentが導入されアプリコンテナの配置先となるホストを分けたいときなどもインスタンスが複数あるCloud Garageさんだと好都合です。

Kubernetes環境としての利用

ぶっちゃけk8sを活用する場合は多くのメモリが必要となるのですが、とりあえず環境をお試し的にサクッと構築するだけであれば2GBもあればなんとか動くことは動きます。

私の契約は2GB x 3BOXなので、Rancher Serverを外部で用意(SaaS的にRancherを試用させてくれるTry Rancherを利用すると簡単)ことで、この契約でなんとかk8sを使うことが出来ます。

先に埋め込んだスライドではまさにこの環境を使ってk8s環境の構築をやっています。メモリ的には結構かつかつですが自分のk8s環境を安価に持てちゃうわけです。

Ansible環境としての利用

業務でAnsibleのトレーニングを担当することがあり、ModuleとかPlaybookとかの確認をやりたい場合に処理対象となるインスタンスを作ったり壊したりできるCloud Garageの環境はやはり便利です。もちろん他のPublic Cloudサービスでも同じことは出来ますが、定額なので作業の途中で一旦手を止めたいときでもコストをさほど気にしないで済むのは気が楽です。

また、最近ですとRed Hat Ansible Towerのコミュニティ版であるAWXの展開先としても利用しています。

こちらもk8sと同様で本来は4GB以上のメモリが推奨なのでややスペック不足ではあるんですが、動作的には問題なく動いています。AWXだけではなく、処理対象となるLinuxサーバを用意できたり、AWXが利用するPostgreSQLを別のホストで動かして接続する・・・といったカスタマイズなども複数インスタンスがあるCloud Garageさんだと気軽に「お、ちょっとやってみるかな」という感じに試せるのがいいですね。

AWXに関しては別のアドカレで記事を書いてますので良かったらご覧ください。

qiita.com

tsukaman.hateblo.jp

まとめ

とまぁ、結局Rancherとk8sとAnsibleだけかよって怒られそうですが、簡単に壊して作り直せたり、途中で放置してまた別のタイミングで続きができるというのはお手軽でとても良い感じです。

自分のPCで仮想マシンによる検証とかだと移動時などでPCをスリープさせるときに「大丈夫かな?」って心配になりますし、仮想マシンを多く立ち上げすぎて他の作業に支障が生じることもあったりするので、やはり外に好きにいじれる環境があるのは便利ですので、普段インスタンスを立てたり壊したりしている人はコストを鑑みてCloud Garageさんの利用を検討してみたりするのもいいんじゃないかなーと思う次第です。

どうしてもWindows環境で作業をしなくてはならないときに使うモノ

マカーというかApple信者です

私、もちろんWindowsUNIX的なものもコレまで所有/使用はしてきたんですが、現時点では仕事もmacOS上でほとんど行うピュアなApple信者です。お布施もバリバリ。いいんです。好きなものは好き。もうずっとマカーなわけです。

しかし窓環境も必要なことはある

まぁ、色々な事情によりどうしてもWindows環境上で作業しないといけないことはあります。誰にでも起こりうることなんです。不可避です不可避。そんなわけで自分がそういうどうしてもWindowsで作業しなくてはいけない場合に使っているモノをご紹介します。

Terminalアプリ

世間一般的にはTera TermさんとかPuttyさんが幅をきかせているんじゃないかなーと思うんですが、私はRLoginを使用しています。

使っている理由としては、開発がきちんと継続的に行われていること、また作者が日本の方なので言語的にも情報にリーチしやすいこと、可搬性が高いことあたりがその理由です。

SSH関連技術周りは色々な理由から変化が速く、きちんと対応がなされているソフトウェアじゃないと常用は不安になります。しかしRLoginは活発に開発がされていますのでその点は安心できるでしょう。開発も現在はGitHubで行われております。

また、日本の方が開発をされてますので、一次情報も日本語で読むことができます。私みたいに英語が得意じゃない人間からすると、やっぱり日本語ベースに情報のやりとりが出来るのは嬉しいです。

あと可搬性についてですが、macOSとかLinuxとかUNIX的なOSとかだと、~/.ssh/config みたいに接続先情報登録するじゃないですか。TeraTermPuttyも同様に登録はできなくもないんですが、その設定を他の環境に持ち出すのが微妙にめんどいんですよね。複数のWindows環境で統一された設定を使いたいときにRLoginは設定をini形式のテキストファイルで管理できるので便利です。

RLoginのインストールページにも書いてあるとおり、exeファイルと同じフォルダ内にRLogin.iniの空テキストファイルを用意してからRLoginを起動すればレジストリではなくこのiniファイルに保存されます。あとは、このexeとiniをクラウドストレージなんかに入れておけば、簡単に複数の環境で同じ設定の元、作業ができることになりますね。

ただし、

※プライベートプロファイルは、複数のプロセスからの変更などに弱いです。また、ファイルベースで意図せぬハングアップやファイルのコピーなどで壊れる場合がありレジストリベースよりリスクが高いと思いますのでご注意ください。

とあるように、iniファイルの破損リスクには注意が必要です(定期的にバックアップをとっときましょう)。

エディタ

この辺は色々好みとか宗教的なアレがありそうなんですが、私にとってWindowsは一時的な作業環境としてちょこっとした作業でしか使いませんので、あまり重いモノは使いたくないんですね。一時的な作業環境なときもありますし。

選択としては、レジストリを汚さない可搬性の高いエディタが最適となります。そんなわけで私は使い勝手の良いシンプルなエディタとしてMeryをオススメしています。

安定版は昨年の更新で止まっているように見えますが、実は定期的にベータ版がリリースされており、作者のkuroさんの開発Blogの文体の面白さもあいまって中々注目しちゃいたくなるアプリケーションです。

今年10月23日にUpされたこの記事によると、ほぼ安定版に近しい状態のベータver 2.6.3がリリースされているようですね。64bit対応もされているご様子。ていうか記事面白い・・・。

Meryそのものは非常にシンプルで使い勝手がとても良いんですが、実際は結構パワフルな機能を持ち合わせていて使っていて困ることはほとんどありません。すっと手になじむ感じですね。

インストールもレジストリを汚さないので、実行ファイルをクラウドストレージあたりに入れておけばいつでも使えて便利です。環境のお掃除したくなっても削除だけでOKってのはやっぱり嬉しいです。

フォント

ぶっちゃけWindows環境での普段の作業だけなら、テーミナルとエディタさえあればなんとでもなっちゃいます・・・。あとはそれぞれのアプリケーションの中で使うフォントですが、ターミナルフォントとしてはMyricaを愛用しています。ミリカって呼ぶらしいです。

日本語も読みやすいので、MeryでもRLoginでも基本コレをつかって表示しています。OneNoteとかを使うときは普通に游ゴシックとかメイリオとかなんですけどね。

まとめ

まぁそんな訳で、たまに使うWindows環境に持ち込むツールのご紹介でした。周りで使っている人があまりいないのでファンが増えてくれると嬉しいにゃー。

Git TownをGithub Enterpriseと一緒に使う

Gitつかってますよね?

開発する人だったら何かしらのバージョン管理システムを利用していると思いますが、その中で最も使われている技術といえばやはりGitでしょう。 また開発にあまり縁がない人、もっと言えば非エンジニアであっても、GithubやGitlabなどを用いればリッチなGUIを使ってチーム内で文章管理が実現できてしまいます。 勝手にドキュメントが上書きされてた!困る!・・・みたいことで困った経験がある方は、Git(Github/Gitlab等)を導入することで、変更点のレビューや反映、ロールバック・・・などの作業が効率よく行えるようになります。

Git(hub/lab)-flowつかってますか?

しかしいくら便利なツールがあっても、チーム内のメンバー各自が自由奔放に更新していっては意味がありません。きちんとコミュニケーションを取りながら、一定のルールのもとで活用してこそ意味があります。

そこで、Gitはこう使うべし!というようなベストプラクティスとも言える考え方がGitーFlowやGithub-FlowやGitlab-flowです。本気でGitを導入したい人は日本語化された記事もあったりしますので一度調べてみるのも良いかもしれません。とはいえ、あくまでもベストプラクティスですし、3つもあってみんな違ってみんな良いかよ!みたいな突っ込みをしたくなるので、まぁ、フワッと理解して実践の中で自分の組織により合った方法を模索していくのが良いのかも知れません。

私の環境では大雑把にこんなルールで運用しています。ちなみにGitHub環境です。

  1. 変更したい場合はmasterから作業用ブランチを切る
  2. 作業用ブランチで変更作業(git add / commit等)をする
  3. Web UI上でPull Request(PR)を作成する
  4. レビュアーにReview / Mergeしてもらう
  5. (不要なら)作業用ブランチを削除する

これらの作業をチーム内で徹底することで、チーム内の共有情報を効率よく複数人で管理していたりします。 ちなみにPRとかMergeされたタイミングなんかでSlack通知させたりもしてます。便利。

Git-Townはいいぞ

ただ、これらの実践には微妙にめんどくさい部分もあります。

  • 毎回ブランチを作成して切り替えるのがめんどい。たまに忘れる。
  • 作業途中にmaster側で変更があったので同期させたいがめんどい。
  • PRのためのWebページを開くのがめんどい。
  • 不要となったブランチをローカルとリモートで削除するのがめんどい。

いずれもまぁ単にめんどくさいってだけなんですが、楽できるなら楽できた方がいいよね。

そこでやくに立つのがGit Townです。

もともと知ったのはMOONGIFTさんの記事だったんですが、しばらく使ってて(私の場合は)特に問題なく便利に使えているのでご紹介したいとおもいます。

Git Townの利点は単純で、前述した作業を非常に簡単に実現できるというところです。 コマンドも必要最低限なのでとても使い易いです。いいぞ。

それでは早速、使い方を見ていきます。

Git-Townのインストール

私の環境はmacOSなので、サクッとHomebrewでインストール可能です。

$ brew install git-town

Homebrewでインストールした場合は、git-townコマンドとしてインストールされます。

また、他環境でもバイナリが用意されてたりするので簡単に導入できそうです。詳しくはGit TownのInstallページをご確認ください。

作業用ブランチを切る

ローカル環境のリポジトリgit-town hack XXXXを実行します。XXXXは作成するブランチ名です。

$ git-town hack new-branch
Git Town needs to be configured

  1: master

Please specify the main development branch by name or number: 1
Please specify a perennial branch by name or number. Leave it blank to finish:

[master] git fetch --prune

[master] git rebase origin/master
Current branch master is up to date.

[master] git checkout -b new-branch master
Switched to a new branch 'new-branch'

$ git branch
  master
* new-branch

途中でメインブランチを聞かれますがmasterを選べば良いでしょう。perennialはぶっちゃけよく分かっていませんがブランクでOKです。まぁ、これだけだったらgit checkout -b new-branch masterと実行してもいいんですけどね。ブランチが複雑な環境で使う場合は、git-townのが扱いやすい気がします(あまりブランチが親子関係をもつような使い方をしたことがない・・・)。

作業開始

必要に応じて変更作業を進めます。git addgit commitすればOKです。いつも通りっすね。

$ echo date > file1.txt
$ echo date > file2.txt
$ echo date > file3.txt
$
$ git add -A
$ git commit -m "adding 3 files"
[new-branch bea7723] adding 3 files
 3 files changed, 3 insertions(+)
 create mode 100644 file1.txt
 create mode 100644 file2.txt
 create mode 100644 file3.txt

この時点でmasterブランチにcommitがあったらどうしたら良いでしょうか? 慌てずにgit-town syncとしてあげれば大丈夫です。

$ ls
README.md  file1.txt  file2.txt  file3.txt
$
$ git-town sync

[new-branch] git fetch --prune
remote: Counting objects: 8, done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 8 (delta 2), reused 1 (delta 0), pack-reused 0
Unpacking objects: 100% (8/8), done.
From (Github EnterpriseのURL):(アカウント名)/tsukaman.test
   2f44349..09c979e  master     -> origin/master

[new-branch] git checkout master
Switched to branch 'master'
Your branch is behind 'origin/master' by 3 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

[master] git rebase origin/master
First, rewinding head to replay your work on top of it...
Fast-forwarded master to origin/master.

[master] git checkout new-branch
Switched to branch 'new-branch'

[new-branch] git merge --no-edit master
Merge made by the 'recursive' strategy.
 NewfileOnMaster1.txt | 1 +
 NewfileOnMaster2.txt | 1 +
 NewfileOnMaster3.txt | 1 +
 3 files changed, 3 insertions(+)
 create mode 100644 NewfileOnMaster1.txt
 create mode 100644 NewfileOnMaster2.txt
 create mode 100644 NewfileOnMaster3.txt

[new-branch] git push -u origin new-branch
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 510 bytes | 510.00 KiB/s, done.
Total 5 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 1 local object.
To (Github EnterpriseのURL):(アカウント名)/tsukaman.test.git
 * [new branch]      new-branch -> new-branch
Branch new-branch set up to track remote branch new-branch from origin.

$ ls
NewfileOnMaster1.txt  NewfileOnMaster3.txt  file1.txt             file3.txt
NewfileOnMaster2.txt  README.md             file2.txt

途中で何を実行したのか表示されるのは良いところですね。ちなみに、Git-TownのデフォルトのPull Strategyはrebaseですがmergeを選択することも可能だそうです。

PRをしてみよう

ではPull Requestしてみます。普通だったらまずリモートの作業用ブランチにCommitをPushしてWebページからPull Requestを作成するのですが、Git-Townではコマンド一発です。

$ git-town new-pull-request
Error: Unsupported hosting service

This command requires hosting on one of these services:
* Bitbucket
* Github
* Gitlab

Usage:
  git-town new-pull-request [flags]

Flags:
      --abort      Abort a previous command that resulted in a conflict
      --continue   Continue a previous command that resulted in a conflict

Unsupported hosting service

This command requires hosting on one of these services:
* Bitbucket
* Github
* Gitlab

おやぁ、、、??エラーになりましたね。

というのも実はこのリポジトリGithub Enteprise上のリポジトリで、要はドメイン名がgithub.comのURLではないんですね。

出力の通りGit-TownではBitbucket、Github、Gitlabのそれぞれに対応しているのですが、今回のエラーはソレのどれかを判別できなかったというものですね。

そこで明示的にGithubを使わせる設定を入れて再実行してみます。

$ git config git-town.code-hosting-driver github
$ git-town new-pull-request

[new-branch] git fetch --prune

[new-branch] git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.

[master] git rebase origin/master
Current branch master is up to date.

[master] git checkout new-branch
Switched to branch 'new-branch'
Your branch is up-to-date with 'origin/new-branch'.

[new-branch] git merge --no-edit origin/new-branch
Already up-to-date.

[new-branch] git merge --no-edit master
Already up-to-date.

open https://(Github EnterpriseのURL)/(アカウント名)/tsukaman.test/compare/new-branch?expand=1

しばらくするとブラウザでPRの画面が開きます。

f:id:tsukaman:20171203173414p:plain

あとは通常通りにPRだしてReviewとMergeを待つ感じです。

不要なブランチの削除

私は作業用ブランチは毎回削除しています。その削除もGit-Townなら簡単です。

$ git-town kill

[new-branch] git fetch --prune

[new-branch] git push origin :new-branch
To (Github EnterpriseのURL):(アカウント名)/tsukaman.test.git
 - [deleted]         new-branch

[new-branch] git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.

[master] git branch -D new-branch
Deleted branch new-branch (was 49435fb).

まとめ

Git-Townは死ぬほど便利!ないと生きていけない!という程ではないのですが、それであると効率よく作業できて嬉しいです。

実はしばらくPRの画面を開くが上手く出来てなかった(なぜかgithub.comが開く)のですが、改めて調べてやってみたらさっくり出来てしまったので今回記事にしてみました。シンプルで使いやすい良いツールだと思いますので皆さんもぜひご賞味ください。

うーまーいぜぇー。

AWX を10分でDeployしちゃうマン(10分でDeployできるとは言ってない)

この記事はAnsible Advent Calendar 2017 - Qiitaの2日目の記事です。

(12/22追記:PostgreSQLのコンテナのデータ保存先がデフォルトでは”postgres_data_dir=/tmp/pgdocker”とデプロイ先の/tmp以下に置かれる設定になっているため再起動時などで削除されてしまう状態でしたので、該当部分の変更を本文中で追記しています。)

どうも、鰻師の方から来ました。

皆さんは日本鰻師同好会という酷いグループをご存知でしょうか。 色々なアドカレに出没しては鰻師の蒲焼きのテーマソング(?)を替え歌にして様々なOSSの普及に努める 酷い 素晴らしいグループです(主な活動は歌って正拳突きをする、です)。

この「Ansible Advent Calendar 2017」もまさか初日と二日目を連続して日本鰻師同好会メンバーに乗っ取られるとは思っていなかったでしょう・・・。しかしご安心ください。初日の初代会長がいろんな意味でgdgdだったので安心して鰻ネタはスルーできます。やったね★

鰻ネタ成分を補充したい人は専用のアドカレがあるのでそっちで補充してください。

adventar.org

ちなみにそもそも鰻ネタの発端となったアドカレはこっち(初日の内容がソレです)。

adventar.org

じゃあAWXの話をしますか。

閑話休題

本日はAnsible TowerのUpstream版であるAWXのデプロイについて書こうと思います。

このアドカレを見るAnsibleが得意なフレンズのみなさんには今更Ansible Towerのことを書く必要は無いと思いますが、AnsibleのCoreな機能にプラスして次のような機能が利用可能になるという素敵ソリューションです。

  • グラフィカルで扱いやすいダッシュボード
  • RBACベースの柔軟な権限管理
  • ジョブスケジューリング
  • 実行監査
  • などなどなど

他にも上げればキリがないのですが、大規模環境でよりセキュアに、よりシンプルに、より便利にAnsibleを使おうと思ったときに大きな威力を発揮するプロダクトといって間違いはないでしょう。しかし、一つ問題が・・・そう・・・利用にはサブスクリプションの購入が前提だったのです・・・。

もちろん、企業内で利用する場合はしっかりとサポートがつくサブスクリプションを購入できることは逆に大きなメリットではあるのですが、やはち有償の製品となると使うにも少し敷居が高かったかと思います(ちなみに10ノードまでは無償利用できます)。

しかしご安心ください。それも既に昔の話。

2017年9月にAWXについてのアナウンスがありました通り、Ansible TowerのUpstream版であるAWXが現在は非常に容易に使えるようになりました(RHELに対するFedoraのような存在だと思ってください)。サポートがなかったりpatchの提供が受けられなかったりという制約はありますが、ひとまず使ってみる分には十分でしょう。AWX ProjectについてはこちらにFAQが用意されているので併せてご確認ください。

そいじゃAWXをデプロイしよう!

今回アドカレでAWXデプロイ話を書くかー!と思って登録したんですが、あらためてググったらサイオステクノロジーさんのOSSよろずブログで既に記事になってました。。もうコレでいいじゃないの?って気持ちになったんですが、少し手を変えて解説したいと思います。

当記事における 変態的 独特なポイントは次の通りです。

  • 展開先ホストではRancherOS 1.1.0を利用します。
  • rootユーザは利用しません。
  • 各AWXのコンテナはRancherで監視します。

お前は何故ソレを・・・といわれそうな部分が多いのですが、まぁあまり気にしないでおきます。 ちなみに私はRancher JPのメンバーでもあり、昨日もRancher Advent Calendar 2017 - Adventarでアドカレを書いていたり・・・。

事前準備:インスタンス作成

今回の環境ですが、毎度お世話になっているCloud Garageさんの上にメモリ2GBのインスタンスをRancherOSで構築します。

細かい手順は省きますが、同様の手順でのRancherOSインスタンスの構築方法を説明したスライドを以前に公開しているので気になる人はそちらをご確認ください。

www.slideshare.net

RancherOSをインストールする際の構成ファイル内容は次の通りです。

cloud-config.yml

#cloud-config
rancher:
  console: ubuntu
ssh_authorized_keys:
  - (ご自分のSSH用秘密鍵に対応する公開鍵情報を記入)

consoleをubuntuとしたのは、あとからPython/AnsibleをインストールしてAWXをデプロイするためです。 このファイルをviで作成後、次のコマンドを実行するとRancherOSがインスタンスの仮想ディスクにインストールされます。

$ sudo ros install -c cloud-config.yml -d /dev/vda

尚、Cloud Garadgeさんを利用している場合は、インストール後にISOマウントを解除した後に強制再起動が必要になるので注意してください(普通の再起動ではダメ)。

再起動後、インスタンスSSHログインし次のコマンドでOSをUpgradeしましょう。

$ sudo ros os upgrade

RancherOSはシステムもDockerコンテナで動いているのでUpgradeも簡単でいいですね。

パッケージのインストール

事前準備で既に10分以上経過している気がしますが、事前はあくまでも事前なのでカウント範囲外とします。しますったらします。

RancherOSではデフォルトでPythonすらインストールされていません。 ここで必要なパッケージをインストールしつつ、Pythonの仮想環境もvirtualenvで作成します。

$ sudo apt update
$ sudo apt upgrade -y 
$ sudo apt install -y git python3-pip
$ sudo -H pip3 install pip --upgrade
$ sudo -H pip3 install virtualenv
$ cd
$ virtualenv venv
$ source venv/bin/activate
$ pip3 install ansible docker-py
$ git clone https://github.com/ansible/awx.git

計測したところ、上記の作業はおよそ5分弱程度でした。

AWX構成ファイル(インベントリファイル)の編集

さてではAWXのデプロイの為に構成ファイルを編集しましょう。今回は時間短縮の為にsedで一気に書き換えます。 変更するのはpythonインタプリターの指定と各種パスワードの値およびPostgreSQLのデータ保存先です。次の例では見やすさの為にコマンドを分けましたが1回で実行しても問題ありません。

$ cd awx/installer/
$ cp inventory inventory.orig
$ sed -i -e '/ansible_python_interpreter/{s#=[^=]*#="/home/rancher/venv/bin/python"#2}' inventory
$ sed -i -e 's/^# default_admin_password/default_admin_password/' inventory
$ sed -i -e '/default_admin_password/{s/=[^=]*/=(adminユーザパスワード)/1}' inventory
$ sed -i -e '/awx_secret_key/{s/=[^=]*/=(シークレットキー)/1}' inventory
$ sed -i -e '/pg_password/{s/=[^=]*/=(データベースパスワード)/1}' inventory
$ sed -i -e '/postgres_data_dir/{s#=[^=]*#="/var/tmp/pgdocker/"#1}' inventory
$ diff inventory inventory.orig
1c1
< localhost ansible_connection=local ansible_python_interpreter="/home/rancher/venv/bin/python"
---
> localhost ansible_connection=local ansible_python_interpreter="/usr/bin/env python"
15c15
< default_admin_password=(adminユーザパスワード)
---
> # default_admin_password=password
20c20
< awx_secret_key=(シークレットキー)
---
> awx_secret_key=awxsecret
30c30
< postgres_data_dir="/var/tmp/pgdocker/"
---
> postgres_data_dir=/tmp/pgdocker
51c51
< pg_password=(データベースパスワード)
---
> pg_password=awxpass

これは一瞬ですね。

AWXのデプロイ

AWXのデプロイではansible-playbookコマンドを利用します。基本的にほっとけばうまいこと全部やってくれるので助かりますね。Ansible便利!

$ ansible-playbook -i inventory install.yml

PLAY [Build and deploy AWX] ***********************************************************************************************************************************

( 中 略 )

PLAY RECAP ****************************************************************************************************************************************************
localhost                  : ok=12   changed=5    unreachable=0    failed=0

おおよそですが、デプロイに要した時間は3分ほどでした。

AWXへのアクセス

さて、デプロイができたのでブラウザから今回デプロイしたホストのIPアドレスをURLとしてアクセスしてみます。 すると・・・

f:id:tsukaman:20171201190453p:plain

ご覧のようにDatabaseのMigration待ちになります。大人しく待ちましょう。 私の環境では、おおよそ2分ほど待っていたらログイン画面が出てきました。

f:id:tsukaman:20171201190629p:plain

ユーザ名はデフォルトのadmin、パスワードは先ほどsedで置換したadminパスワードを入力してログインします。

f:id:tsukaman:20171201190636p:plain

これでデプロイ完了です。事前準備を除けば、だいたい10分くらいでデプロイできたのではないでしょうか。

Rancherでコンテナを監視してみる

ここから完全にオマケです。

これまで使った感じですとPostgreSQLのコンテナが死んでしまうことが何度かありました。原因がはっきりわからないのですが、Restartが何らかの理由で掛かってしまってその際に/tmp/pgdocker以下のデータベースデータがおかしくなってしまうようでした。同様の症状はググると他にもみつかるので、今後はもう少しなんとかなるかもしれません。

ひとまず各コンテナを管理しやすくするためにRancherの力を借りたいと思います。前述のSlideShareの中でも書いていますが、GitHubのアカウントさえあれば誰でもTry Rancherを無料で利用できるので、こちらを流用してコンテナの監視をしてみたいと思います。

TRY Rancherへログイン&ホスト追加

これはGitHub認証するだけなので楽ちん。詳しい流れは上の方のSlideShareのやつをみてね。 ログインが出来たら今回はいきなりホストの追加に進みます。画面上ホストの追加のリンクボタン(または文字列)が表示あると思いますのでクリックしてください。

ホストの追加画面ではCustomを選択し、5番目の手順にあるコマンドをメモリにコピーします。 コピーしたコマンドを今回AWXをデプロイしたRancherOS上で実行すれば、あとは勝手にTry Rancherにホストが追加されて各コンテナが管理可能な状態になります。

ホストが追加されたら画面上部のインフラストラクチャの中にあるコンテナのメニューを選択します。 Rancherのコンテナもインストールされてますが、AWXに関するコンテナを確認できます。

f:id:tsukaman:20171201194909p:plain

尚、AWXに関するコンテナは次の5つです。

  • awx_task
  • awx_web
  • memcached
  • postgres
  • rabbitmq

ここでは、awx_taskのコンテナ名をクリックしてみましょう。すると、Rancher UI上でコンテナのUsage情報を確認できます。

f:id:tsukaman:20171201195350p:plain

また右上にあるボタンをクリックするとメニューが開くので、

f:id:tsukaman:20171201195448p:plain

ここからのコンテナのlogを確認したり、

f:id:tsukaman:20171201195452p:plain

シェルを起動して操作することも可能です。

f:id:tsukaman:20171201195455p:plain

まぁ、この辺はdockerコマンドでやってももちろんいいんですけどね。お好きなほうをご利用くださいませ。

まとめ

なんかすごい脱線した気もするのですが、AWXのデプロイはいかがだったでしょうか。

リリース直後は公式Dockerイメージもなくて毎回Imageをビルドしていたのでものすごく時間かかっていたんですが、公式Dockerイメージが用意されたことでかなり簡単にAWXも使えるようになったと思います。是非冬休みのお供にAWX(とRancher)を使ってみてください。

明日は@mnagakuさんの投稿だそうです。内容はなんだろう・・・。鰻ではないはず。

RKEってなんじゃ?

この記事は Rancher Advent Calendar 2017 - Adventar の1日目の記事です。

師走になりました

泣いても笑っても2017年もあと一ヶ月となってしまいました。 年を取ると時間の流れが速くなると言いますが、ここ数年をそれを痛いほど実感する毎日です・・・。

さて、速いと言えば我らがRancherの進化スピード・・・といいつつ、こちらは逆に最近落ち着いてますね。 来年早々にはKubernetesを中心に据えたRancher 2.0がリリースされる様子で今はそちらに多くの開発リソースを注ぎ込んでいる真っ最中かなーと想われます。 12月にリリースされるとXmasプレゼント的な感じでナイスだった気もしますが、まぁそのぶん良いものが出てくることを願いましょう。

Rancher JPコミュニティについて紹介するよ(ていだったよ)!

さて本稿はRancherアドカレの記事ですが、マニアックな技術的投稿は他の人に丸投げして今回はコミュニティの話を書きたいと思います。 ・・・いや正確には思っていたんです。しかし、昨日たまたま次のアドカレを見つけてしまってコミュニティのことはそっちで書くことにしました。

adventar.org

というわけで少し思い直して牛可愛いよポエムでも書こうと思ったら別のメンバーに止められたので最近のニュースの話にします。

RancherがRKEを産んだってさ!

正直アルファベット3文字略語は紛らわしいので好きではないのですが、Rancherさんもやってしまいました。 Rancher Kubernetes EngineRKEです。最近こんな名前のやつばっかりだな・・・。

つい先日の11月29日のことですが、Rancherの開発および商用サブスクリプションの提供をする企業であるRancher LabsのブログにてこのRKEに関する投稿がいくつかなされました。

Announcing RKE, a Lightweight Kubernetes Installer | Rancher Labs

An Introduction to Rancher Kubernetes Engine (RKE) | Rancher Labs

日本語がとくいなフレンズのためにGoogle翻訳さんがうまいこと訳してくれたページも貼っとくね。

軽量KubernetesインストーラRKEを発表 | Rancher Labs

Rancher Kubernetes Engine(RKE)の紹介 | Rancher Labs

こちらの記事に書いてあるとおりRKEはGo言語で書かれた軽量k8sインストーラだそうです。

Rancherとk8s

Rancher 1.xでもk8s環境構築が出来ることは牛Loveなフレンズもご存知の通りです。これについては以前に私もプレゼンしてスライドを共有しているので興味のある方はそちらをご覧ください。

www.slideshare.net

じゃあなんでRKEを?という話なんですが、最初のほうの記事にあるようにRancherとk8sの独立性を高めることが目的と考えられます。つまり、Rancher側の障害でk8s環境が止まったりしないようにするためですね。

現在、Rancher LabsはRancher 2.0の開発をモリモリモーモー頑張っている真っ最中です。

記事中にも少し書いてありますが、Rancher 1.xがマルチコンテナオーケストレーションツール(Cattle、Kubernnetes、Mesos、Swarm、Windows Container)の対応だったのに対して、Rancher 2.0では思いっきりKubernetesに舵を切ったものに化けてしまいます。1.xの一部の資産は引き継げるようにするっぽいFAQはあるのですが、どっちかというと(マルチ)k8s環境を管理するツールとして頑張っていくぜ!的な方向のようです。

Rancherが何でもかんでも全部やるというよりは、誰が(何が)つくったk8sであっても簡単に管理ができるようにするためのRancherという位置を目指しているんじゃないかなーという感じ。

実際、最近のコンテナ界隈を見渡してみると猫も杓子もみーんなk8sベッタリで、「僕たちk8sできるフレンズだよ!」って言わないとヤバイ的なオーラさえ漂っています。もちろんk8s自体は大変素晴らしい仕組みですしコンテナオーケストレーションツールの大本命であることは間違いないと思いますが、ユーザサイドからみると「デプロイツールも環境もこんなに選択肢があって何を選べばいいのよ」状態に陥っていくような気配を感じる次第です。

Rancherは以前からそもそもマルチな環境にデプロイできたり、マルチなオーケストレーションツールに対応したりと、あまり1つのものに絞り過ぎないような方針をとっているように思います。今回2.0でk8sに絞っては居ますが、それでもマルチなk8sを見据えて開発を進めているんかなーと個人的に妄想しています。実際そうなのかは知らんけど(おい)。

んじゃ早速

まぁ、誕生の理由はさておき早速RKEを使ってみます。現時点ではRKE v0.0.7-devがGitHubで公開されており、環境としてmacOSまたはLinux上で利用できるようです。

今回はお試しということで、RancherOSの仮想マシンを3台立て、ホスト側のmacOSからRKEを試してみましょう。

  • ホスト環境

  • VM

    • vCPU: 2core
    • vMem: 2GB
    • vDisk: 200GB(Thin)
    • OS: RancherOS 1.1.0
    • Docker: 1.12.6

ここではRancherOSのインストール手順は省略します。前出のスライドにRancherOSインストール詳細な手順があるので、必要な場合はそちらをご覧ください。 また、バージョン1.12.xのDockerがインストールされていてSSHアクセスが可能で実行ユーザがdockerを使用できる状態であれば他のOSでも大丈夫なようです(RancherOSはこれらの要件を全て楽に満たせるので使いました)。

ちなみに、RKEは実行時、SSH接続用秘密鍵をデフォルトで~/.ssh/id_rsaとして見にいくようです。現時点では、鍵のPATHを指定する方法が分からなかったので今回はホスト側の~/.ssh/id_rsaに対応するid_rsa.pubをRancher OSには登録しています。

  • cloud-config.yml参考
#cloud-config
rancher:
  docker:
    engine: docker-1.12.6
ssh_authorized_keys:
  - ( ~/.ssh/id_rsaに対応する公開鍵情報 )

RKEの入手

既にmacOS向けのBuild済みのバイナリパッケージがRKEのGitHub Releaseページで公開されていますので、ここからrke_darwin-amd64をクリックして適当なダウンロードします(ファイル名はrke_darwin-amd64.dmsになります)。

このままではコマンドとして実行しづらいのでリネームしましょう。また、実行権も付けて実行できることを確認します。

$ mv rke_darwin-amd64.dms rke
$ chmod +x rke
$ ./rke
NAME:
   rke - Rancher Kubernetes Engine, Running kubernetes cluster in the cloud

USAGE:
   rke [global options] command [command options] [arguments...]

VERSION:
   v0.0.7-dev

AUTHOR(S):
   Rancher Labs, Inc.

COMMANDS:
     up              Bring the cluster up
     remove          Teardown the cluster and clean cluster nodes
     version         Show cluster Kubernetes version
     config, config  Setup cluster configuration
     help, h         Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --debug, -d    Debug logging
   --help, -h     show help
   --version, -v  print the version

cluster.ymlの作成

実行できることを確認したので、インストールのためのYAMLファイルを作成します。 RKEではcluster.ymlがデフォルトのクラスター構成ファイル名になるようです。

$ vi cluster.yml

尚、内容は前述のBlog記事を参考にこんな感じにしてみました。

---
nodes:
  - address: 192.168.101.148
    user: rancher
    role: [controlplane]
  - address: 192.168.101.149
    user: rancher
    role: [worker]
  - address: 192.168.101.150
    user: rancher
    role: [etcd]

services:
  etcd:
    image: quay.io/coreos/etcd:latest
  kube-api:
    image: rancher/k8s:v1.8.3-rancher2
  kube-controller:
    image: rancher/k8s:v1.8.3-rancher2
  scheduler:
    image: rancher/k8s:v1.8.3-rancher2
  kubelet:
    image: rancher/k8s:v1.8.3-rancher2
  kubeproxy:
    image: rancher/k8s:v1.8.3-rancher2

_・).。oO(DockerHubみてみたらv1.8.3-rancher3ってイメージも既にありそう・・・)

k8sのインストール

では、準備が出来たら早速upしてみましょう。

$ ./rke up
INFO[0000] Building Kubernetes cluster
INFO[0000] [ssh] Checking private key
INFO[0000] [ssh] Start tunnel for host [192.168.101.150]
INFO[0000] [ssh] Start tunnel for host [192.168.101.148]
INFO[0000] [ssh] Start tunnel for host [192.168.101.149]
INFO[0000] [state] Found local kube config file, trying to get state from cluster
INFO[0000] [state] Fetching cluster state from Kubernetes
INFO[0030] Timed out waiting for kubernetes cluster to get state
INFO[0030] [certificates] Generating kubernetes certificates
INFO[0030] [certificates] Generating CA kubernetes certificates
INFO[0030] [certificates] Generating Kubernetes API server certificates
INFO[0031] [certificates] Generating Kube Controller certificates
INFO[0031] [certificates] Generating Kube Scheduler certificates
INFO[0032] [certificates] Generating Kube Proxy certificates
INFO[0032] [certificates] Generating Node certificate
INFO[0032] [certificates] Generating admin certificates and kubeconfig
INFO[0032] [certificates] Deploying kubernetes certificates to Cluster nodes
INFO[0052] [certificates] Successfully deployed kubernetes certificates to Cluster nodes
INFO[0052] [etcd] Building up Etcd Plane..
INFO[0052] [etcd] Pulling Image on host [192.168.101.150]
INFO[0056] [etcd] Successfully pulled etcd image on host [192.168.101.150]
INFO[0056] [etcd] Successfully started etcd container on host [192.168.101.150]
INFO[0056] [etcd] Successfully started Etcd Plane..
INFO[0056] [controlplane] Building up Controller Plane..
INFO[0056] [controlplane] Pulling Image on host [192.168.101.148]
INFO[0061] [controlplane] Successfully pulled kube-api image on host [192.168.101.148]
INFO[0061] [controlplane] Successfully started kube-api container on host [192.168.101.148]
INFO[0061] [controlplane] Pulling Image on host [192.168.101.148]
INFO[0065] [controlplane] Successfully pulled kube-controller image on host [192.168.101.148]
INFO[0065] [controlplane] Successfully started kube-controller container on host [192.168.101.148]
INFO[0065] [controlplane] Pulling Image on host [192.168.101.148]
INFO[0069] [controlplane] Successfully pulled scheduler image on host [192.168.101.148]
INFO[0069] [controlplane] Successfully started scheduler container on host [192.168.101.148]
INFO[0069] [controlplane] Successfully started Controller Plane..
INFO[0069] [worker] Building up Worker Plane..
INFO[0069] [worker] Pulling Image on host [192.168.101.148]
INFO[0073] [worker] Successfully pulled kubelet image on host [192.168.101.148]
INFO[0073] [worker] Successfully started kubelet container on host [192.168.101.148]
INFO[0073] [worker] Pulling Image on host [192.168.101.148]
INFO[0077] [worker] Successfully pulled kube-proxy image on host [192.168.101.148]
INFO[0078] [worker] Successfully started kube-proxy container on host [192.168.101.148]
INFO[0078] [worker] Pulling Image on host [192.168.101.149]
INFO[0082] [worker] Successfully pulled nginx-proxy image on host [192.168.101.149]
INFO[0082] [worker] Successfully started nginx-proxy container on host [192.168.101.149]
INFO[0082] [worker] Pulling Image on host [192.168.101.149]
INFO[0086] [worker] Successfully pulled kubelet image on host [192.168.101.149]
INFO[0087] [worker] Successfully started kubelet container on host [192.168.101.149]
INFO[0087] [worker] Pulling Image on host [192.168.101.149]
INFO[0091] [worker] Successfully pulled kube-proxy image on host [192.168.101.149]
INFO[0091] [worker] Successfully started kube-proxy container on host [192.168.101.149]
INFO[0091] [worker] Successfully started Worker Plane..
INFO[0091] [reconcile] Reconciling cluster state
INFO[0091] [reconcile] This is newly generated cluster
INFO[0091] [certificates] Save kubernetes certificates as secrets
INFO[0109] [certificates] Successfuly saved certificates as kubernetes secret [k8s-certs]
INFO[0109] [state] Saving cluster state to Kubernetes
INFO[0109] [state] Successfully Saved cluster state to Kubernetes ConfigMap: cluster-state
INFO[0109] [network] Setting up network plugin: flannel
INFO[0109] [addons] Saving addon ConfigMap to Kubernetes
INFO[0109] [addons] Successfully Saved addon to Kubernetes ConfigMap: rke-netwok-plugin
INFO[0109] [addons] Executing deploy job..
INFO[0124] [addons] Setting up KubeDNS
INFO[0124] [addons] Saving addon ConfigMap to Kubernetes
INFO[0124] [addons] Successfully Saved addon to Kubernetes ConfigMap: rke-kubedns-addon
INFO[0124] [addons] Executing deploy job..
INFO[0129] [addons] KubeDNS deployed successfully..
INFO[0129] [addons] Setting up user addons..
INFO[0129] [addons] No user addons configured..
INFO[0129] Finished building Kubernetes cluster successfully

kubectlの実行

無事にupが成功したら、カレントディレクトリに.kube_config_cluster.ymlというファイルが作成されていますので、これを~/.kube/configにコピーします。 このファイルはkubectlコマンド実行時に読み取られ、今回インストールしたk8s環境を制御可能とします。ちなみにkubectlコマンドはmacOSの場合、HomeBrewで簡単にインストールできます。

$ ls -a
./                        ../                       .kube_config_cluster.yml  cluster.yml               rke
$ cp .kube_config_cluster.yml ~/.kube/config
$ kubectl get nodes
NAME              STATUS    AGE       VERSION
192.168.101.148   Ready     14m       v1.8.3-rancher1
192.168.101.149   Ready     14m       v1.8.3-rancher1

_・).。oO(ここのバージョンはrancher1でいいのかしら。。。)

無事にインストール出来たご様子です。Blogの内容を見ると、他にもHA構成を取ってみたり、ノードの追加/削除をしたりと、RKEではいろいろ出来そうですね。

k8s環境の削除

とりあえず今回はここまでとして、最後にお掃除してみたいと思います。

$ ./rke remove
Are you sure you want to remove Kubernetes cluster [y/n]: y
INFO[0002] Tearing down Kubernetes cluster
INFO[0002] [ssh] Checking private key
INFO[0002] [ssh] Start tunnel for host [192.168.101.150]
INFO[0002] [ssh] Start tunnel for host [192.168.101.148]
INFO[0002] [ssh] Start tunnel for host [192.168.101.149]
INFO[0002] [worker] Tearing down Worker Plane..
INFO[0002] [remove/kubelet] Checking if container is running on host [192.168.101.148]
INFO[0002] [remove/kubelet] Stopping container on host [192.168.101.148]
INFO[0002] [remove/kubelet] Removing container on host [192.168.101.148]
INFO[0002] [remove/kubelet] Sucessfully removed container on host [192.168.101.148]
INFO[0002] [remove/kube-proxy] Checking if container is running on host [192.168.101.148]
INFO[0002] [remove/kube-proxy] Stopping container on host [192.168.101.148]
INFO[0002] [remove/kube-proxy] Removing container on host [192.168.101.148]
INFO[0002] [remove/kube-proxy] Sucessfully removed container on host [192.168.101.148]
INFO[0002] [remove/kubelet] Checking if container is running on host [192.168.101.149]
INFO[0002] [remove/kubelet] Stopping container on host [192.168.101.149]
INFO[0002] [remove/kubelet] Removing container on host [192.168.101.149]
INFO[0002] [remove/kubelet] Sucessfully removed container on host [192.168.101.149]
INFO[0002] [remove/kube-proxy] Checking if container is running on host [192.168.101.149]
INFO[0002] [remove/kube-proxy] Stopping container on host [192.168.101.149]
INFO[0002] [remove/kube-proxy] Removing container on host [192.168.101.149]
INFO[0002] [remove/kube-proxy] Sucessfully removed container on host [192.168.101.149]
INFO[0002] [remove/nginx-proxy] Checking if container is running on host [192.168.101.149]
INFO[0002] [remove/nginx-proxy] Stopping container on host [192.168.101.149]
INFO[0003] [remove/nginx-proxy] Removing container on host [192.168.101.149]
INFO[0003] [remove/nginx-proxy] Sucessfully removed container on host [192.168.101.149]
INFO[0003] [worker] Successfully teared down Worker Plane..
INFO[0003] [controlplane] Tearing down the Controller Plane..
INFO[0003] [remove/kube-api] Checking if container is running on host [192.168.101.148]
INFO[0003] [remove/kube-api] Stopping container on host [192.168.101.148]
INFO[0003] [remove/kube-api] Removing container on host [192.168.101.148]
INFO[0003] [remove/kube-api] Sucessfully removed container on host [192.168.101.148]
INFO[0003] [remove/kube-controller] Checking if container is running on host [192.168.101.148]
INFO[0003] [remove/kube-controller] Stopping container on host [192.168.101.148]
INFO[0003] [remove/kube-controller] Removing container on host [192.168.101.148]
INFO[0003] [remove/kube-controller] Sucessfully removed container on host [192.168.101.148]
INFO[0003] [remove/scheduler] Checking if container is running on host [192.168.101.148]
INFO[0003] [remove/scheduler] Stopping container on host [192.168.101.148]
INFO[0003] [remove/scheduler] Removing container on host [192.168.101.148]
INFO[0003] [remove/scheduler] Sucessfully removed container on host [192.168.101.148]
INFO[0003] [controlplane] Successfully teared down Controller Plane..
INFO[0003] [etcd] Tearing down Etcd Plane..
INFO[0003] [remove/etcd] Checking if container is running on host [192.168.101.150]
INFO[0003] [remove/etcd] Stopping container on host [192.168.101.150]
INFO[0004] [remove/etcd] Removing container on host [192.168.101.150]
INFO[0004] [remove/etcd] Sucessfully removed container on host [192.168.101.150]
INFO[0004] [etcd] Successfully teared down Etcd Plane..
INFO[0004] [hosts] Cleaning up host [192.168.101.148]
INFO[0004] [hosts] Running cleaner container on host [192.168.101.148]
INFO[0004] [kube-cleaner] Pulling Image on host [192.168.101.148]
INFO[0009] [kube-cleaner] Successfully pulled kube-cleaner image on host [192.168.101.148]
INFO[0010] [kube-cleaner] Successfully started kube-cleaner container on host [192.168.101.148]
INFO[0010] [hosts] Removing cleaner container on host [192.168.101.148]
INFO[0010] [hosts] Successfully cleaned up host [192.168.101.148]
INFO[0010] [hosts] Cleaning up host [192.168.101.149]
INFO[0010] [hosts] Running cleaner container on host [192.168.101.149]
INFO[0010] [kube-cleaner] Pulling Image on host [192.168.101.149]
INFO[0017] [kube-cleaner] Successfully pulled kube-cleaner image on host [192.168.101.149]
INFO[0018] [kube-cleaner] Successfully started kube-cleaner container on host [192.168.101.149]
INFO[0018] [hosts] Removing cleaner container on host [192.168.101.149]
INFO[0018] [hosts] Successfully cleaned up host [192.168.101.149]
INFO[0018] [hosts] Cleaning up host [192.168.101.150]
INFO[0018] [hosts] Running cleaner container on host [192.168.101.150]
INFO[0018] [kube-cleaner] Pulling Image on host [192.168.101.150]
INFO[0023] [kube-cleaner] Successfully pulled kube-cleaner image on host [192.168.101.150]
INFO[0024] [kube-cleaner] Successfully started kube-cleaner container on host [192.168.101.150]
INFO[0024] [hosts] Removing cleaner container on host [192.168.101.150]
INFO[0024] [hosts] Successfully cleaned up host [192.168.101.150]
INFO[0024] Cluster removed successfully

無事にお掃除も完了です。

まとめ

いかがだったでしょうか。

個人的には簡単ではあるものの、まだまだベータなので柔軟性や拡張性が十分とは言い切れないなーという感じでした。 とはいえ一般的にはまだ難しいと言われるk8sのインストールを、タダでさえ構築が簡単だったRancher 1.xよりも更に簡単に構築出来ること、またRancher自体から独立できることは耐障害性の面でも利点なのかなと思います。コンテナネットワークもデフォルトのFlannel以外にもCalicoやCanalを容易に選択できるようです。このあたりはまた色々試してくれる人が現れることを祈って・・・(他力本願)。

以上、 Rancher Advent Calendar 2017 - Adventar の1日目の記事でした。明日はおすぎ(ピーコ?)アイコンでおなじみの良太郎さんによる牛ポエムだそうです。え、いいの?