ErgoDox EZを買ってみて1週間使った感想
現状です pic.twitter.com/3uz87gumsf
— ひらしー (@y05_net) 2016年5月23日
参考にしたページ
- 公式サイト
ここから購入 - Ergodox EZ を使ってみよう
- 漢のコンピュータ道|キーボードを新しくした話(ErgoDox)
Ergodox EZやErgodoxが何であるかを知るのにこちらを参考にしました - キーマップのやり方(mac)
- デフォルトキーマップの画像
購入したきっかけ
キーボードのこだわりはない派だったので、可も不可もないbuffaroあたりやmac pro備え付けのものを使ってましたが長時間使用していて疲れないという触れ込みのkinesisはちょっと気になっていました。(同時に価格的に気軽に試せないかなとも。。。) 色々な所でErgodox EZの噂を聞き、築いていたらポチっていることに
Ergodox EZ円高なので衝動買いしてた
— ひらしー (@y05_net) 2016年5月2日
尚、色々とパーツ毎に買えるらしいが不足があって買い足すのもメンドそうなので$295の「ErgoDox EZ Bundle: Blank」に
到着まで
注文後にキースイッチをどれにするかメールで聞いてくるので公式サイトに「Quiet, great for office use.」を掲載されていたBrownにした。
5/2に注文して5/16に届いたので2週間。
自分の場合はUPSの配達だったが不在だったので不在票に書かれていた電話番号に連絡したら簡単に再配達の手配(再配達はヤマト運輸だった)をしてもらえた。
ErgoDox EZ届いてた(不在なので土曜再配達)
— ひらしー (@y05_net) 2016年5月16日
届いた pic.twitter.com/nG8Vkp5y3e
— ひらしー (@y05_net) 2016年5月21日
物理的な使用感
コネクタ・アクセサリについて
- 余計なパーツがなく、リストレストも本体の形状に合わせて作ってあることもありしっくり来たので「ErgoDox EZ Bundle: Blank」を選んで正解だった
- USBが若干長めなのでデスクトップ用途でもラップトップでも丁度良く、追加購入する手間が省けた
- キーボードの高さを調整できるパーツが金属製でしっかり作ってあった。最初、調整に六角の金具が必要かと思ったが、指で締めただけでも安定しているので自分にとってはデメリットではなかった
- 会社でmac proをマジックトラックパッド2と使用しているのでUSBポートが足りず、USBハブを使うことになった。欲を言えばカスケードできるポートが付いていたらと思った。
キーボード使用感
- レイヤ機能(特定キーで全てのキーマップを変えられる)はまだ有効に使えておらず。とりあえず、キーマップに試行錯誤中
- 打鍵感は正直高級キーボードを使ったことがあまりないので、あまり良くわからないがストロークも有り、不快感はない
- 打鍵音はBrown(「Quiet, great for office use.」)を選んだはずだがオフィスだと若干大きいかも
キーマップ
正直一番好き嫌いが別れるのがこのキーマップだと思う。デフォルトだと特に記号が謎のキーマップなので自分にとっては超絶使いづらかった。
もちろんErgoDox Ezは全てオープンソースでツールも充実している。macを持っていれば慣れれば1,2分でキーマップを再構成させることが可能。
(尚、キーマップ変更で最初に詰まったのは物理リセットボタンが深すぎて押せない所、コンビニで売っているゼムクリップを伸ばして使うのが最適解だと思う)
現状は、このようなキーマップに落ち着いている(というかだいぶ変更している)
- Shift,Ctrl,Alt,Cmd,かな、英数をmac pro USキーボードの場所っぽくした
- Escapeキーはvimでよく使うので右手親指で
- 十字キー、マウス機能をホームポジションで使えるようにした。(正直マウス機能はあまり使ってない)
- 記号全般のキー配置がイケてないので、レイヤ2でUSキーボードの場所っぽくした。(これはまだ試行錯誤中)
- 脳が追いつかなくなるので?レイヤ3は使わない予定
1週間使った感想
左右分離+ポジション調整できるキーボードになっただけでも長時間使用時の疲労は減った気がするが、キーマップがどうカスタマイズしても特殊にならざるを得ないので慣れるまでは相殺されている気がする。
あと、慣れたらもう通常のキーボードが苦痛で使用できない気もするので(特にキーマップ弄ったら)ある程度このキーボードと心中する覚悟が必要かも。
gemを作った時に複数サーバにRundockでシュッとインストールする
概要
gemのツールを作った時、bundle exec rake releaseでrubygemsにアップロードしてからツールを使う複数のサーバにインストールする際、わざわざAnsibleやChefといった構成管理を使うのも面倒臭かったで、RundeckにビルトインのRake Taskを実装して、使ってみた時の知見
前提
既にbundle exec rake releaseでrubygemsにアップロードできる環境があるものとします
準備
- gemspecファイルに以下の1行を追加
spec.add_development_dependency 'rundock'
- Rakefileファイルに以下の1行を追加
require 'rundock/gem/tasks'
- パッケージをインストールして確認
$ bundle install $ bundle exec rake -T
- 以下の行が表示されればok
rake rundock # Run rundock with default configuration rake rundock:do # Run rundock with scenariofile.(env:SCENARIO_FILE_PATH)
# ホスト毎にタスク実行の流れを書く - target: client-01 task: - gem_install - target: client-02 task: - gem_install --- # インストールしたいサーバのsshログイン情報 # sshオプションのport,user,keyは省略可能 client-01: host: 192.168.1.11 ssh_opts: port: 22 user: anyuser key: "~/anyuser/id_rsa_any" client-02: host: 192.168.1.12 ssh_opts: port: 22 user: anyuser2 key: "~/anyuser/id_rsa_any2" --- # タスク(gemのインストールの実処理の配列) gem_install: command: - "echo \"start: `hostname`\"" - "sudo gem install <your gem name>"
実行
$ bundle exec rake release $ bundle exec rake rundock
成功すれば以下の様な結果になるはず
start: client-01 Fetching: your_gem-x.x.x.gem (100%) Successfully installed your_gem-x.x.x 1 gem installed start: client-02 Fetching: your_gem-x.x.x.gem (100%) Successfully installed your_gem-x.x.x 1 gem installed
RundockというYAMLベースな構成管理ツールを作ってみた
RundockというYAMLベースな構成管理ツールを作ってみました
経緯
以前からChef(Chef-Solo) や itamae といった構成管理ツールを使っているのですが、複数サーバにおける即時実行管理までサポートしてないので他のツールを選定していたのと、現在選定の結果として使用している Rundeck というsshベースの構成管理ツールの弱点をなんとかしたいと思い、軽い気持ちで車輪の再発明してみました。
前提
AWSやオートスケーリングに対応した環境を前提に考えるとcloud-initやrc.local、最近ではTerraformを使用してプロビジョニングするほうがスマートではあるので、sshでログインして管理したほうが都合が良い混み入った事情があるレガシーな環境やアドホックにちょっとしたサーバの情報を収集、設定をする用途に限定されます。
解決したかった点
複数の環境の異なるサーバに対してアドホックに任意の構成管理の処理を実行することと実行結果をトレースできること。
この点ではRundeckでそれをほぼ満たしていると思っているのですが、唯一実行計画をYAMLやXML等のテキストファイルでバージョン管理し辛いことが不満でした。*1
設計思想と利用させて頂いたOSS
設計思想としてはUNIX哲学である”一つのことをうまくやれ”に従い、"複数以上の環境への実行管理"に特化しており、環境の取り扱い(backend)と実行の内容(operation)は全てプラグインにすることを目指しています。*2
backendについては現在mizzy氏のspecinfraを利用させて頂いております。
また、実装について多くの箇所でitamaeを参考にさせて頂きました。(特にログ周り)
実行例
インストール
$ gem install rundock
プラグインは"rundock-plugin-[プラグインタイプ]-[プラグイン名]"の命名規則のgemパッケージを判別して自動でロードされます
$ gem install rundock-plugin-operation-itamae
実行に必要な設定ファイル
itamae用
- nginx.rb
package 'nginx' do action :install end service 'nginx' do action [:enable, :start] end template "/var/www/html/index.html" do source "/tmp/index.html.erb" end
- index.html.erb
<%= node[:name] %>
Rundock用
Rundockでは"---"で別れたドキュメントのYAMLを使います。(ドキュメント毎に別のファイルを指定することも可能)
- scenario.yml
- target_group: hiracy-dev command: hostname itamae: - /path/to/nginx.rb # recipe files - sudo: true # itamae --sudo option - node_json: /path/to/attr.js # itamae --node-json option # you can use itamae any options here --- hiracy-dev: target_type: group targets: - hiracy-dev-01 - hiracy-dev-02 hiracy-dev-01: host: 192.168.10.121 # specify ssh options(Net::SSH options compatible) ssh_opts: port: 22222 user: hiracy_01 key: ~/.ssh/id_rsa_hiracy_01 hiracy-dev-02: host: 172.16.10.122 # use ssh_opts by ./default_ssh.yml
詳細はwikiのほうを見て頂きたいのですが、"itamae ssh"とオプションをYAMLファイルの中で指定しています。
また、"command"という項目を見て分かる通り、単純なコマンド実行をデフォルトでサポートしています。
実行
$ rundock do /path/to/your/scenario.yml
--dry-runオプションを付けることで実際には実行せずにログ出力だけすることが可能です
$ rundock do /path/to/your/scenario.yml --dry-run
フック
ノードやグループ単位の実行後にフックを仕掛けることも可能です。こちらも全てプラグインにしています。
サンプルとしてSlackに実行後のログを送るプラグインを使ってみます。
$ gem install rundock-plugin-hook-slack
- scenario.yml
- target_group: hiracy-dev command: hostname itamae: - /path/to/nginx.rb # recipe files - sudo: true # itamae --sudo option - node_json: /path/to/attr.js # itamae --node-json option # you can use itamae any options here hook: - hook_slack --- hiracy-dev: target_type: group targets: - hiracy-dev-01 - hiracy-dev-02 hiracy-dev-01: host: 192.168.10.121 # specify ssh options(Net::SSH options compatible) ssh_opts: port: 22222 user: hiracy_01 key: ~/.ssh/id_rsa_hiracy_01 hiracy-dev-02: host: 172.16.10.122 # use ssh_opts by ./default_ssh.yml --- # task section(no use in this case) --- hook_slack: hook_type: slack token: xxxx-9999999999-999999999-99999 # token argument(required) channel: my_channel # channel argument(required) username: rundock-bot # username(optional) icon_url: http:/hiracy.org/rundock-bot.png # icon_url(optional)
実行
$ rundock do /path/to/your/scenario.yml
課題
Rundeckの場合だと実行履歴の検索・フィルタリングが優れているので保管するプラグインを作ってみてもいいかもしれない。
後はYAMLファイルを再利用してtmuxでコンソールを直接開く機能は良いと思いますね。
最後に
A○sibleやFabricに不満がありましたらこちらにプルリク送ってみたりプラグイン作成してみてはいかがでしょうか!!!
Linuxでサマータイムが切り替わる瞬間について
海外向けのサービスのためにLinuxでサマータイムのある地域のタイムゾーンを設定することもあるかと思いますが、サマータイムに切り替わる瞬間にどうなるのか気になったのでちょっと試してみました。
[条件]
- dateコマンドでPST(太平洋標準時)がサマータイムに入る/戻る瞬間
- 環境:CentOS6.4 Kernel: 2.6.32-358.el6.x86_64
- 実行方法:一時的に時間変更した後、watchコマンドで1秒毎に経過監視
[サマータイムに入る瞬間]
[サマータイムから戻る瞬間]
この通り 2015年のサマータイムにて PST(太平洋標準時)からPDT(太平洋夏時間)にかけてdateコマンドの結果取得が瞬時に切り替わることがわかります。 もちろんdateコマンドの表示フォーマットを変えても同じ結果となります。
phpやrubyといったプログラム言語で時間取得していた場合はどうなるでしょう
続きを読むITインフラ 業務自動化現状確認会で発表してきました
2014/10/7 ITインフラ業務自動化現状確認会で発表して参りました!!
続きを読むCentOS5からCentOS6へ移行する際にサーバ構築でハマりそうな箇所のメモ
最近CentOS5系からCentOS6系にシステムを移行する機会がありましてその時サーバ構築でハマりそうになった箇所のメモです webサービスで利用するための最小限の構成なので用途によっては他のハマり所があると思うので悪しからず
- yum groupinstall のパッケージ内容の違い
- bashバージョンアップによるシェルスクリプト正規表現判別文法の違い
- resolv.confの"options single-request-reopen"対応
- sysctlのip_conntrackからnf_conntrackへの名称変更
- NetworkManargerのoff
- ユーザ毎のプロセス数制限デフォルトポリシーの変更