2017-12-06

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

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

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

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

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

Terminalアプリ

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

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

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

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

あと可搬性についてですが、macOSとかLinuxとかUNIX的なOSとかだと、~/.ssh/config みたいに接続先情報登録するじゃないですか。TeraTermもPuttyも同様に登録はできなくもないんですが、その設定を他の環境に持ち出すのが微妙にめんどいんですよね。複数の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環境に持ち込むツールのご紹介でした。周りで使っている人があまりいないのでファンが増えてくれると嬉しいにゃー。

2017-12-03

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環境です。

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

これらの作業をチーム内で徹底することで、チーム内の共有情報を効率よく複数人で管理していたりします。ちなみに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 addやgit 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が開く）のですが、改めて調べてやってみたらさっくり出来てしまったので今回記事にしてみました。シンプルで使いやすい良いツールだと思いますので皆さんもぜひご賞味ください。

うーまーいぜぇー。

2017-12-02

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」もまさか初日と二日目を連続して日本鰻師同好会メンバーに乗っ取られるとは思っていなかったでしょう・・・。しかしご安心ください。初日の初代会長がいろんな意味でｇｄｇｄだったので安心して鰻ネタはスルーできます。やったね★

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

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インスタンスの構築方法を説明したスライドを以前に公開しているので気になる人はそちらをご確認ください。

Rancherで作るお手軽コンテナ運用環境!! ～ Kubenetes & Mesos 牧場でコンテナ牛を飼おう！～ from Masataka Tsukamoto

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さんの投稿だそうです。内容はなんだろう・・・。鰻ではないはず。

2017-12-01

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 EngineでRKEです。~~最近こんな名前のやつばっかりだな・・・。~~

つい先日の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なフレンズもご存知の通りです。これについては以前に私もプレゼンしてスライドを共有しているので興味のある方はそちらをご覧ください。

Rancherで作るお手軽コンテナ運用環境!! ～ Kubenetes & Mesos 牧場でコンテナ牛を飼おう！～ from Masataka Tsukamoto

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を試してみましょう。

ホスト環境
- マシン: MacBook Pro (13" 2016）/ 3.3GHz Core i7 / 16GB
- OS: macOS High Sierra 10.13.1（17B1002）
- 仮想化ソフト: VMware Fusion 10.0.1 (6754183)
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日目の記事でした。明日はおすぎ（ピーコ？）アイコンでおなじみの良太郎さんによる牛ポエムだそうです。え、いいの？

2017-07-30

なながつのおもいで的な

早いもんで

気づいたら7月も終わりな訳ですよ。

うっかり前回の日記的なやつから一ヶ月以上空いちゃってるんですが、まぁそれだけ忙しいのかなんなのか、充実した日々を送っていると勝手にしておきましょう。

そんなわけで、最近の私を振り返っておきたいと思います。

お仕事のこと

けっこう相変わらずです。OpenStack的なモノが中心ですが、合間にコンテナ的なこととかクラウド的なこと（OpenStackもクラウド的なものだけど）をやってます。来月からAnsibleのトレーニング的なことも携わる予定なので今はその準備におろおろしています。

お仕事以外のこと

Rancher JPのコミュニティ活動を盛んに行っています。主に賑やかし要員ですが。 LTで話したり、運営としてかけずり回ったり。

お陰で知り合いも増えて、他のコミュニティの情報やらも前よりもキャッチできるようになりました。世の中には面白い技術は多いけど、全部追うには時間が足りないですねー（寝たいので許して）。

おうちのこと

上の息子さんが相変わらず試験という試験（スイミング、算盤、合気道）に合格しまくっています。合格したらベイブレードのベイを買うって話で当初進めてたんだけど、あまりに合格ばかりなので奥さんが「なんでそんなに買わなきゃならんのだ」となってしまいました。息子さんも合格したら買ってもらって当たり前という態度がちょっとどうなのよ？という感じでもあるので少し方針変更中だったりします。

あ、ついでですが私も合気道の試験（6級ですが）合格しました。まだ白帯。息子さんは青帯に進化しててずるい。

下の息子さんは相変わらず顔はすげー可愛いけど超うるさくて性格が悪いです。昨日、保育園の夕涼み会のお化け屋敷でギャン泣きして暴れました。可愛いやつめ。このちっこいさんもスイミングを春から始めて先日初めての試験に合格しました。ご褒美はハイチュウ。すごい大事に食べてる。かわいい。

この先のこと

8月から9月にかけて色々お話する機会を頂いています。LTじゃなくて少し長めの尺のやつです。

8月なのにJulyでおなじみの”JTF（July Tech Festa）”では、前述のRancherについてお話しする機会を得ました。最近注目されまくりのコンテナオーケストレーター”Kubernetes”とDCリソースがっつりおまとめで有名な”Mesos”のクラスターデプロイについて話しますよ。

9月になると、毎度おなじみOSC Tokyoで前回と同じ入門トラックの”Linuxインストールの話”と、やはりRancher JPの”Rancherでk8s牧場を作ろう”ってかんじの話をします。

専業講師から兼業講師にジョブチェンジはしちゃいましたが、今でもやっぱり人前で話すのは好きなんだなぁと思います。

＿・）みなさん聞きにきてね！

2017-06-17

＿・）さいきんの活動記録みたいな

お久しぶりです

書こう書こうと思いつつ、すっかり間が空いてしまいました。ここしばらく公私ともに忙しくてやっとすこーしだけ落ち着いた感じがするようなしないような・・・。

今日は、最近何をやってるの？ってことを主に記録しておこうかと。

まずはお仕事

私よりも忙しい人をあげればきりが無いのですが、ここ最近はそれなりにお仕事もやることが色々できたりして忙しくしていました。暇で暇で仕方なくなったらそれはそれでヤバイので良いことですね。

家庭は、というと

息子さんの運動会のせいで腕がこんがり焼けてしまいました。誰が焼豚だ。中途半端な袖の長さにしてしまっていたせいで、変なポッキー焼けしちゃっています。しかも左右の腕で焼け具合が違うという・・・。

あとはまぁいつも通りでしょうか。

あ、上の息子さんのスイミングが気づいたら随分進んでて、5月末にはなんとバタフライの科目にも合格しちゃいました。あいつ、試験という試験に最近ずっと合格しているなぁ・・・。

実は息子さんとは、試験に合格したらご褒美でベイブレードバーストのベイを1個買うって感じの約束をしちゃっています。スイミングに算盤と最近はずっと合格続きの負け知らずなのでかなり良いペースでベイを買わされちゃっています。まぁ、楽しそうにいっつもベイシュートしているのでいいか・・・。

合気道も頑張っています

4月からお世話になっている養神館合気道光龍館も、継続して毎週土曜日に3時間ほど稽古しています。 5月の後半には、浦安市の総合体育館で複数流派で合同の演舞大会にも参加してきました。まだまだ初心者なのでちっともサマにはなっていないのですが、日進月歩という感じで基本を覚えているところです。

7月には初めての試験（6級〜8級を目指すらしい）もありますので、まずはその合格が当面の目標ですね。

コミュニティ活動とかも増えました

仕事に関連もするからというと身も蓋もないんですが、ここのところ色んな勉強会への参加が増えました。また、Rancher JPやMUGTと言ったコミュニティ運営にも少し関わるようになってきてて、何かと忙しさに拍車をかける原因にもなっています。

とはいえ、最新の技術に触れられる良い機会ですし、そうした技術のコミュニティに集まっている人達も皆さん優秀で素晴らしいので、今後も色々とガンバってやっていこうと思っているところです。えいえいおー。

おまけ

Nintendo Switchほしい・・・けど買ったところでやる暇ないだろうなぁ。

2017-05-08

＿・）RasPi2でTV録画サーバ

やっとTV録画サーバ直した

前々回くらいでOSC Tokyoにも展示したRasPi2を使った地デジ録画サーバ。

その後、なぜかchinachuでTV番組表が更新できなくなり、あれこれするうちに録画ができなくなって、あー直さなきゃなーと思ってたやつをGW中に直しました。

以前はOSMCで構築したんですが最近はLibreELECなんてメディアセンター向けOSがRaspberry Piも主流になってきているみたいで、よーしこいつでつくるか！！！と思ったらパッケージの手動追加とかめんどくさそうになってたので諦めてサクッとRaspbianで作ってみました。

いやー、標準OSはやっぱり楽でいいですね。

参考にしたのは

以前は誰かのBlog記事を参考にしたんですが、ちょうど良くまとまってるQiita記事があったのでこれを参考にしました。

qiita.com

Chinachuも以前よりもバージョンアップしててインストール。。。というか管理の仕組みががらっと変わったんですね。こちらは公式のページを参考にインストールしました。

「七森中録画研究会」スペシャルサイト

いきなりデーンとアニメ画がでますが、公式がこんな感じなので戸惑わないように・・・。

とりあえずは健全に動いてます

番組表も無事に取得できたのでとりあえず今晩のベイブレードから録画する予定。予約もサクッとDone。Chinachu便利。

どうか無事に録れるますように・・・。