Other」カテゴリーアーカイブ

チーム開発を活性化するためにやったこと

最近STNSのバージョンアップ記事ばっかり書いていたので、今日はチーム開発について書いてみます。僕は2016年からペパボのエンジニア職位制度のミドル層にあたるシニア・エンジニアという職位につきました。シニア・エンジニア以上の職位についてはエンジニアとして優れた存在であり続けることはもちろんのこと、それに加えて社内のエンジニアの育成や、社の全体の技術的課題の解決が求められます。

自身がなんからのプロダクトを生むことや、社の課題を解決するのは自分で手を動かせばよいだけなので、特に何も考える必要はありませんでした。対して社内のエンジニアの育成を考えた場合に、僕はまずはチームをいかに活性化し、生産性を高めるか?という事を考えました。
その理由は下記の3つです。


1. 生産性が上がるとこなせる仕事量が増加し、その結果、経験値が蓄積しやすい。
2. 生産性が上がると無駄に残業せずに早く帰れて最高!!(自己研鑚の時間が出来る)
3. 生産性が上がると、なんか自分やれてる感が生まれて更に頑張るから成長する


チームとしての生産性を上げるために半期中にいくつか施策を打ちました。その中から今日は3つを紹介します。

自動テストで記法チェック、自動修正を導入する

コードレビューをする際に、例えばphpであれば下記のようなコードが書かれていた場合。

if($hoge == "fuga"){
  echo "check";
}

ifと(の間にはスペースを入れましょうなどといった指摘って、言われた方も正直どうでもいいと思うってしまうし、言う方もタイプする時間が無駄ですよね。何も生まない指摘はしないに越したことはないので、下記のようなコードをCIツールで自動実行しています。

# !/bin/bash

success=0
files="$(git diff --name-only --diff-filter=M origin/master HEAD | grep ".php$")"
rootdir=$(cd ../$(dirname $0) 2>/dev/null;pwd)

if [ `which php-cs-fixer` ]; then
    cmd=php-cs-fixer
else
    cmd=$rootdir/vendor/bin/php-cs-fixer
fi

array=($(echo $files))
for file in $(echo $files); do
  echo "php-cs-fixer fix $file;"
done
echo

for file in $(echo $files); do
    info "$file"
    php -l $file && $cmd fix $file --dry-run --diff
    test $? -ne 0 && success=1
done

exit $success

内容的にはGitHubのmasterのHEADと比較し、差分があるファイルに対して、php-cs-fixerというPHPの自動記法チェック、修正ツールを実行しています。記法に誤りがあれば、下記のようにコマンドを発行し、自動で修正しています。

$ php-cs-fixer fix path/to/file.php

ちなみにこのスクリプトは同僚の@linyowsさんが作っていたものをこっそり拝借させてもらいました。これによりチーム内でどうでもいい指摘によるモチベーションのダウンや、レビューにかかる時間を短縮し、生産性を上げることが出来ます。

botによるチームタスク管理

Webサービスの運用においては日々様々なインシデントやバグの顕在化が起こります。そういったタスクは突発的に起こり、多くの場合に即日対処が求められます。タスク管理ツールについてはたくさんありますが、僕のチームではSlack+GitHubIssue+Rubotyを利用しています。例えば何らかのタスクが発生した場合は下記のようなコマンドをSlackに発行します。

osadakun_issue

issue

そうすると、GitHub上にラベル日直を付与されたIssueが作成されます。作成されたIssueにインシデントや対応の内容を記載します。追加されたタスクについては下記のようにコマンドを発行し確認することが出来ます。
osadakun_list

また決まった時間(16時とか)に自動でSlackにコマンドが発行される仕組みがあるため、タスクの漏れを防ぐことが出来ます。
この運用のメリットは下記のとおりです。


1.コミュニケーションツールとタスク管理が一つのインターフェースになる
2.ホワイトボードなどを利用しなくても、全員が同じ画面をみて会話することが出来る
3.GitHubのIssueと組み合わせることでFlow情報とStock情報両方が管理できる


特に2.ホワイトボードなどを利用しなくても、全員が同じ画面をみて会話することが出来るについてはSlackのタスクリストを見ながら、「このタスク今どうなってるんですか?」「それはIssueのこの部分に書いてある」と言った会話が何気なく出来るのってすごく便利です。
またIssueのクローズとともにタスクリストから消えるので消えないIssue=終わってないタスクということで管理がし易いです。
これに加え中長期的なタスクについてはTrelloを利用し、週に1回のタスクミーティングでタスク管理をしています。

コードレビューを定時化

これは結構個人的な話なのかもしれないのですが、僕自身がSlackのメンションとトークが苦手で、メンションやトークのたびに集中が止まるのがすごく勿体無く思えています。特に複数人で開発していると、コードレビューお願いします @dev-teamみたいなメンションが人数分飛ぶわけで、開発のスピードが上がれば上がるほどメンションされる回数が増えてきます。そのたびに集中が途切れるのは非常に勿体無いので、レビュー待ちというラベルをGitHubに作成し、そのラベルが付与されたPRを定期的に通知する仕組みを作成しました。

osadakun_review

こうすることにより例えば、10時、11時・・・のように定時で通知し、通知された時に一斉にレビューすることにより、AさんとBさんの言ってることが違う問題や何度も時差的にコメントが付いてそのたびに対応して時間を失うようなことが軽減できます。

最後に

今回は生産性を上げるという観点で記事を書きました。僕が取ったアプローチは大きくまとめるとチームで嫌と思うことを減らすということです。嫌だと思うことを取り除くことで、結果的に生産性の向上に寄与できる部分はあるのかなと考えています。下期は時間を作って学問的にチームビルディングを学びたいと考えているので、良書があればぜひ教えて下さい!

WEB+DB PRESS Vol.92に寄稿しました。

このたび技術評論社より発売されたWEB+DB PRESS Vol.92に寄稿させていただきました。
僕は「特集1-Web開発新人研修-5章 インフラを構築しよう」を担当しています。

きっかけ

ペパボの同僚である@june29さんが技術評論社からお声がけ頂いた企画を社内のエンジニアで書いてみないか?という提案があり、僕自身はこれまで執筆の経験がなく不安もあったのだが、これは売名行為にはうってつけだ!!!と思い、真っ先に手を上げたことからだった。

前職を辞めるときに、

「僕は一年後にはカンファレンスに聞きに行く側じゃなくて、しゃべる側になる。そのうち本も書いてみせる」

なんて言っていたので、ペパボに入って1年半くらいで書けたのは環境の力って本当にすごいなぁという気持ちです。

書いてみて

Itamaeを利用してインフラをコード化するという内容で6ページ書かせていただきました。
最初は「1200文字×6ページで7200文字か・・・」と思っていましたが、書き出すと溢れるくらいになってしまい、意外と書けるものですね。

分担という観点では今回は全体7名で6章を分担して執筆し、うち5名が初執筆でした。
ほぼ全員が初執筆で余裕がなく、前後のつなぎがどうしても直近での調整となってしまい、多少ドタバタした面はありましたが、調整役に徹してくれた@june29さんのおかげで上手く収まった感があります。
そして、ぎりぎりまで書き換えてくれたくろくんは本当にご苦労様。

また今回はGitHub上で執筆、レビューを行うという方法を採用しました。
その際に一つ一つの章が個々人の創作物であるため、どこまで突っ込んで良いのかというのが個人的にはもやっとしていたのですが、ここでも@june29さんの必ずポジティブから入り、配慮しつつも核心をついてくる指摘ってすごいと感心すると共に、チーム開発の練度高いんだろうなと伺い知るところでした。

まとめ

楽しかったです。そして今回の執筆はチーム作業での振る舞いや、ある種プロジェクトを円滑に進めるためのテクニックが間接的に学べてかなり良かった。
またやったことないことでも、不安があっても、「俺やるっす」ってどんどんいってくのほんとに大事なんで、みんなやっていこうな。

Mackerel運用を支える仕組み

ペパボでムームードメインの開発運用を担当している@pyama86です。

このエントリはMackerel Advent Calendar 2015の12月14日のエントリです。昨日は@ariarijpさんによるエントリでした。

はじめに

ペパボでは従来よりサーバ監視の多くがNagiosにより行われていました。しかし昨今では、クラウドとの相性の良さからMackerelによるサーバ管理へと移行しつつあります。このエントリでは細かい管理の紹介については以前筆者がMackerel MeetUp #5で登壇した際の資料に譲り、Mackerelを大規模導入した際に起こりがちな問題を検知する仕組みを紹介します。

  • ロールに属していないホストを検知する
  • 開発、検証環境ホストへのインストールを検知する
  • 退役忘れホストを検知する
  • オーバースペックなホストを検知する

ロールに属していないホストを検知する

Mackerelにおいては御存知の通りロールを軸として様々な監視、管理を行うことが出来ます。ホストをロールに所属させるにはmackerel-agent.confに定義、APIを用いて操作いずれかの作業が必要ですが、その作業の両方を行っていない場合、ロールに所属しないホストが出来てしまいます。そうなってしまった場合に、気づくにはmkrコマンドでmkr hosts | jq -r '.[] | select(.roleFullnames == null)'とするか、WEBUIから探し出すといった作業が必要になります。これを自動で検知すべくペパボでは筆者が開発したmalsh(マルシェ)というコマンドを利用しています。malshは同僚の@ryutaro_mizokamが開発しているmackerel-rbを利用して各APIの実行結果をSlackに通知することができるコマンドです。筆者の使用方法としてはwheneverと組み合わせて下記のような使い方をしています。

%w(
  MACKEREL_APIKEY
  SLACK_WEBHOOK
  SLACK_CHANNEL
  SLACK_USER
).each do |e|
  env e.to_sym, ENV[e]
end
every :day, :at => '1:00pm' do
  command "/path/to/bin/malsh maverick"
end

これだけの定義で毎日13時にSlackに対してロールに所属していないホストを通知することが出来ます。

marveric

ちなみにmaverickの由来はこのコマンドを書いている時に、映画「トップガン」をながら見していて、作品中でのトム・クルーズの役が一匹狼の凄腕パイロットmaverickであったことに由来します。(トム・クルーズ最高!!!!)

開発、検証環境ホストへのインストールを検知する

puppet,chef,itamaeでのインフラ管理が当たり前となった昨今においてはMackerelのインストールにおいてもコード・自動化していることがほとんどだと思います。しかし新たにレシピを書いた際についつい分岐を入れ忘れたりして、開発、検証環境に誤ってMackerelをインストールしてしまうことも少なくないのではないでしょうか?解決策としてmalshではホスト名で検索し、通知することが出来ます。他にもやり方としてはIPアドレスがローカルアドレスであるというような条件付けも可能に思えますが、現状はホスト名による検知で問題なく運用出来ています。

/path/to/bin/malsh search -e local dev -v exclude.local --subject 不要ホスト候補一覧

この定義ではホスト名にlocalもしくはdevを含むかつexclude.localを含まないホストを、不要ホスト候補一覧という件名でSlackに通知しています。

退役忘れホストを検知する

Mackerelのライセンスはホスト単位となっており、出来るだけ費用を抑えるには、無駄なインストールはしない、必要のないホストは退役させるこれに尽きます。ただし、ライセンスの体系は必ずしもインストール数ではありません。以下公式FAQより引用

1時間程度以内の間隔で定期的にアクティブなホスト数をカウントします。
ホストのステータスに関わらず、メトリック投稿APIにアクセスしたユニークなホスト数を計上します。
通常はmackerel-agentの起動数となります。
退役(Retired)状態のホストはアクティブなホストとしてカウントされません。
30日間、もしくはこれまでの利用済み期間の短かい日数の平均を計算し、その値を利用しているホスト数とします(端数切り上げ)。

上記のホストのステータスに関わらず、メトリック投稿APIにアクセスしたユニークなホスト数を計上します。に注目して、malshでは過去5分のロードアベレージの投稿がないにもかかわらず、Mackerelに登録されているホストを検知することが出来ます。

/path/to/bin/malsh retire

本来であればAUTO_RETIREMENT(自動退役)使えばよい話なのですが、AUTO_RETIREMENT自体がリリース時から使えたわけではなく、またsystemd環境での動作がうまくいってなかったこともあり、必ずしも全ホストにAUTO_RETIREMENTを適用できていないケースも多いのではないかと思います。そういった場合にこの通知を行うことによって退役忘れを防ぐことが出来ます。

オーバースペックなホストを検知する

冒頭で申したとおり、Mackerelはクラウドとの相性が非常によく、AWSやOpenStackと合わせて利用しているユーザーも多いのではないでしょうか?いずれにおいてもインスタンスの費用はスペックに応じて高くなる傾向があり、逆に言えばインスタンスのスペックを低くすればコストを抑えられる事になります。malshでは先日リリースされたグラフメトリックデータ取得APIを利用してCPU、Memory過去N日間の最高使用率がXX%を下回っているホストを検知することが出来ます。

/path/to/bin/malsh search -memory 40 -cpu 40 -subject '過去7日間CPUとMemoryの最高使用率が40%以下のホスト一覧'

過去N日間のデフォルトは7日間で、月次バッチなどを考えると1ヶ月(–past_date 30)といった運用も良いのではないかと思います。またCPU、Memory単独でのしきい値指定も可能です。この通知を行うことによって、ついつい安心モードで大きく作ってしまうインスタンスを見直すきっかけを生み出すことが出来ます。

最後に

本エントリではMackerelを使って何かをすることではなく、Mackerelを上手く運用する幾つかの手段について紹介しました。これまでの監視ツールと異なり、監視対象側に設定の多くを持つことから導入の手間が少ない反面、全体的な管理がしにくい部分もあります。その部分はAPIが提供されているので、上手く利用し、足りない部分を自分たちの運用に合わせて実装していけばより良い運用になると考えます。

そしてグラフメトリックデータ取得APIなど、多くの要望をはてな社に送り、順次対応していただけていることから今後も出来ることが広がり、サーバ監視からよりサーバ管理により近づいていくことが期待できるので、ぜひMackerel利用してみてはいかがでしょうか?

明日は@fujiwaraさんです。

もうLDAPにさよなら?SSHログインの公開鍵をGitHubから取得する方法

今日は簡単なシェルスクリプトでGitHubから公開鍵を取得してSSHログインを行う方法を紹介したいと思います。
ポイントとしてはsshd_configで以前紹介したAuthorizedKeysCommandを利用すること、
次にGitHubはhttps://github.com/<user_name>.keysで登録されている公開鍵を取得できる仕組みを利用します。
設定例はCentOSを前提に記載しています。

事前準備

GitHubから公開鍵を取得する際にAPIを利用します。
APIの利用にはトークンが必要なためこちらの手順に沿ってトークンを取得して下さい。
またcurl,jqコマンドを利用するため、インストールが必要です。

yum -y install curl jq

設定例

  • /etc/ssh/sshd_config
~
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/git_auth.sh
AuthorizedKeysCommandUser root
~
  • /usr/local/bin/git_auth.sh
#!/bin/sh
curl -s -u "<username>:<token>" https://api.github.com/users/$1/keys | jq -r '.[].key'

ログインする

これだけでOSにユーザーが存在していれば公開鍵ログインできてしまいます。

$ ssh pyama@example.com
Last login: Wed Sep 16 11:25:48 2015 from examle.com

[pyama@example.com ~]$

このケースですとログイン先のサーバにOSにpyamaユーザーが存在しなければログインすることは出来ません。
これがある意味ログイン制御になるのですが、GHEなどを導入しているとか、IP制御で社外からアクセス出来ないとか、
ログイン自体の制限をする必要がない場合は、強気にこういったシェルでも良いのではないでしょうか。

  • /usr/local/bin/git_auth.sh
#!/bin/sh
useradd $1 >/dev/null 2>&1
mkpasswd -l 8 $1 >/dev/null 2>&1  # コンソールログインをしない想定でランダムなパスワードを設定
curl -s -u "<username>:<token>" https://api.github.com/users/$1/keys | jq -r '.[].key'

まとめ

LDAPを導入した場合と比べ、ログイン可能ユーザー制御など細かいことは出来ませんが(やろうと思えば出来なくもない)、
パスワードログインをとにかく撲滅して、楽に公開鍵SSHログインしたいケースでは便利なのではないでしょうか。

Mackrel Meetup #5に登壇してきた

ども。
玄界灘のイケメンです。

9/17に渋谷マークシティのサイバーエージェントセミナールームにて株式会社はてな主催で行われました
Mackerel Meetup#5に登壇してきました。
イベントの内容は公式ブログにて紹介されております。
「Mackerel Meetup #5」を開催しました

Mackerel is 何

Mackerel(マカレル)は、運用中のクラウドもしくはオンプレミスのサーバにエージェントを1つ入れるだけで、簡単にサーバ管理を始められます。監視サーバ自身の構築・運用は不要です。さらに負荷のリソース状況などの数値をグラフに可視化します。障害発生時にはアラートが記録され、様々なツールに通知できます。システム運用保守に最適な監視ツールです。(公式サイトより)

これまでの監視ツール(Zabbix,Nagios)と異なり、設定の主体が被監視サーバであることが非常に特徴的で、
昨今のコード化されたインフラと非常に相性が良いです。
VM起動してプロビジョニングされた時から監視を始めることが出来き、プロキシ環境もサポートしているので
環境の制限を受けることなく利用する事ができます。

僕自身は開発エンジニアをやっているムームードメインを始め、社内プライベートクラウドのNyahのOpenStack基盤にも全面導入しています。

今回僕が登壇した際に喋った内容はペパボでのNagiosから移行する際にNagiosプラグインがそのまま使えて比較的容易に移行できたこと、
自分たちでプラグインを書くことによってあらゆる値が監視可能になったことなど話してきました。

参加者の方々と懇親会で話した限りではまだ導入に至ってない方が多かったことからもうちょっと移行周りの話を濃ゆくすればよかったなぁと反省しつつも、少しでも参考になっていれば幸いです。

感想

今回が東京のイベントで喋る機会として初めてでした。
福岡と比べて懇親会の参加率とかすごく高くて、数名の方に声もかけていただき、非常にアグレッシブでした。

反省はペパボに入ってからあえて名刺持たないようにしていたのですが、割りと名刺持たれてる方が多くて
そろそろ作らなきゃなぁと。。。

最も良かったことはナイフのような男だと思い込んでいた@y_uuk1さんが非常に温厚でいい人だったことです。
はてなの方々本当に親切でナイスガイが多かったです。

スクリーンショット 2015-09-19 23.58.28

最後にMackerel本当にいいプロダクトなんで今後もより良くなっていくように上手に使っていきたい、
そして僕らも監視の工数減った部分を上手に使ってより良いサービス作っていきたい。

IMG_20150917_200419Samsung Galaxy Nexus (3.43mm, f/2.75, 1/33 sec, ISO125)

プレゼンするたびにサブスクリーンに変なの映るんでなんか良いソフト入れたい。

Vagrant + Chefな環境でbondingを構築する。

あるじゃないですか?
扉とかに 「押」「引」の文字。
僕、常に押すんですよね。

あ、どうもP山です。

Vagrant + chefな環境において限りなく本番環境に近づけたいときに、
NICって結構悩むと思うのですよね。

本番環境はbondingつかってNICを冗長化しているけど、検証だからNIC一個で!が多いとは思いますが、
やってみたのでご紹介。

まずchefにはifconfigというリソースがあって、それを使うとifcfgファイルがDSLで書けるのですが、
そのDSLにMASTERの項目がないので、今のバージョンでは少なくともbondを定義するのは厳しそうでした。

やろうと思うとtemplate(もしくはcookbook_file)でやることになり、それがこんな感じ。

Vagrantfile

  config.vm.define :compute do |c|                                                                                                                                                                    
    c.vm.network :private_network, autoconfig: false, virtualbox__intnet: "intnet"
    c.vm.network :private_network, autoconfig: false, virtualbox__intnet: "intnet"
    c.vm.network :private_network, autoconfig: false, virtualbox__intnet: "intnet"
    c.vm.network :private_network, autoconfig: false, virtualbox__intnet: "intnet"
    c.vm.provision :chef_zero do |chef|
      chef.add_role 'compute'
    end 
  end 

ポイントはautoconfig: falseにしてあげることで、自動設定を無効化します。

cookbook

template/ifcfg.conf

DEVICE=<%= @device %>                                                                                                                                                                               
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes

files/default/ifcfg-bond0

DEVICE=bond0
BOOTPROTO=none                                                                                                                                                                                        
ONBOOT=yes
BONDING_OPTS="mode=4 miimon=100 lacp_rate=slow xmit_hash_policy=layer3+4"

今回はIPふってないですが、こちらはifcfgと同じくIPもふることができます。

recipe/default.rb

1.upto(4).each do |i| 
  template "/etc/sysconfig/network-scripts/ifcfg-eth#{i}" do
    source  'ifcfg.conf.erb'
    owner   'root'
    group   'root'
    mode    '0644'
    variables ({
      :device => "eth#{i}"
    })  
    notifies :restart, 'service[network]'                                                                                                                                                             
  end
end

cookbook_file "/etc/sysconfig/network-scripts/ifcfg-bond0" do
  owner   'root'
  group   'root'
  mode    '0644'
  notifies :restart, 'service[network]'
end

service 'network' do
  action :nothing
end

結果

bond0     Link encap:Ethernet  HWaddr 08:00:27:85:8E:95  
          inet6 addr: fe80::a00:27ff:fe85:8e95/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:99 errors:0 dropped:0 overruns:0 frame:0
          TX packets:62 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:12138 (11.8 KiB)  TX bytes:6308 (6.1 KiB)

eth0      Link encap:Ethernet  HWaddr 08:00:27:E9:00:C8  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fee9:c8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:204841 errors:0 dropped:0 overruns:0 frame:0
          TX packets:106154 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:166813970 (159.0 MiB)  TX bytes:6079495 (5.7 MiB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:85:8E:95  
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:24 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2976 (2.9 KiB)  TX bytes:1928 (1.8 KiB)

eth2      Link encap:Ethernet  HWaddr 08:00:27:85:8E:95  
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:25 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3054 (2.9 KiB)  TX bytes:1460 (1.4 KiB)

eth3      Link encap:Ethernet  HWaddr 08:00:27:85:8E:95  
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:25 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3054 (2.9 KiB)  TX bytes:1460 (1.4 KiB)

eth4      Link encap:Ethernet  HWaddr 08:00:27:85:8E:95  
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:25 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3054 (2.9 KiB)  TX bytes:1460 (1.4 KiB)

eth5      Link encap:Ethernet  HWaddr 08:00:27:42:B8:F6  
          inet addr:10.52.2.21  Bcast:10.52.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe42:b8f6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:80243 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4889556 (4.6 MiB)  TX bytes:2460 (2.4 KiB)

eth6      Link encap:Ethernet  HWaddr 08:00:27:9C:41:7D  
          inet addr:10.52.1.21  Bcast:10.52.1.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe9c:417d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:36984 errors:0 dropped:0 overruns:0 frame:0
          TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2294016 (2.1 MiB)  TX bytes:2544 (2.4 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

こんな感じでbondが組めるようになります。
ifconfigリソースのPRは夏休みの宿題ってことで!

ほな!

黒川温泉産のLDAPサーバでSSH公開鍵認証する

ども。
温泉太郎ことP山です。

週末社内のSlackで@antipopさん、@hsbtさん、@buty4649さんと雑談していて、gcloudっぽく楽にログインしたいっすよねーっていう話をしていて、↓こんな感じ。

$ gcloud compute ssh <インスタンス名> --zone <ゾーン名>

このあたりを大いに参考にさせてもらいつつ、温泉に入りながらリゾートワークならぬ湯治ワークで土台となるcookbook書いた。

内容としてはLDAPサーバ1台とsshログインされるサーバが1台立ちます。
sshログインされるサーバに対して指定されたユーザーでssh接続を行うと、
sshログインされるサーバがLDAPにクエリを投げ、該当のユーザーの公開鍵を取得し、
取得できれば公開鍵ログインが行われるという感じです。

ちなみに取っ掛かりなSampleCookBookなので

「あー、なるほど、こんな設定すればいいんだ!!」

くらいに思ってもらえると幸いです。

確認環境

  • Vagrant 1.7.4
  • VirtualBox 5.0.0

使い方

$ bundle install
$ vagrant plugin install vagrant-properties
$ vi roles/ldap.json #公開鍵を設定してください
$ vagrant up
$ ssh 192.168.70.11 -l test

ひと通りの動作が確認できると重います。
特徴としては下記のtemplateで定義されているdescriptionでログイン可能サーバの制御を行っていて、
pyamaユーザーはmuuサービスlolipopサービスにログインできるが、その他はできないという
ような制御を可能にしています。

LDAPの登録内容

cookbooks/ldap/templates/default/auth.ldif.erb

dn: uid=pyama,ou=ssh,dc=pepabo,dc=com
objectClass: shadowAccount
objectClass: posixAccount
userPassword: test
description: muu
description: lolipop
sshPublicKey: ssh flkjdaldjsflasjdflajdalfkjs

ログインされるサーバの設定内容

cookbooks/client/templates/default/nslcd.conf.erb

uid nslcd
gid ldap
uri ldap://192.168.70.10/
base ou=ssh,dc=dummy,dc=com 
ssl no
tls_cacertdir /etc/openldap/cacerts
filter passwd (description=muu) # このサーバにはdescription=muuを持つユーザーだけがログインできる
filter shadow (description=muu)
filter group  (objectClass=posixGroup)

tips

通常ではLDAPに公開鍵を登録することはできないので、こちらを参考に該当のリソースを追加するldifを作成し登録してたりします。

久しぶりにLDAP触って疲れた・・・

第2回ペパボテックカンファレンスで登壇してきた

Hello Ikemen!!!
新しい言語を触る時は必ず実行します、
山下です。

さて、昨日ペパボテックカンファレンスが行われ、
当社のOpenStack事例を話してまいりました。

前日から配信周りのお手伝いをしたり、自分たちの手作りイベントだったので
非常に楽しかったです。
配信担当の@Elek1torさん本当に有難うございました。

カンファレンスの内容は、トップバッターを務めた@matsumotoryさんが快調なスタートをきってくださいました。
特に技術力がすごいのはもちろん、周りを巻き込んで引き上げていく力が尋常ではなくて
勢いあるし勢いださせてるなぁと感じました。

通りすがりのいけすかないGopherのライブコーディングや、zではない方のうづらさんの
巻き込むような司会・プレゼンも見事でした。

また前職でお付き合いのあった山本さんも足を運んでいただき有難うございました!
そしてご挨拶できずにすみませんでした。

イベントのまとめは最近ムームードメインに入ったムーキムさんがまとめてくれているので
第2回ペパボテックカンファレンスin福岡にいってきました
こちらをご参照下さい。

動画のアーカイブも出ているのでぜひ見て下さいね!
2:58:00くらいから動いている僕が見れますが、会場を爆笑に巻き込んだ部分は音声がないです。
本当に笑いの絶えない時間だったのでお届けできないのが残念です。

PHPカンファレンス福岡で登壇してきた

ども、いつもどおりイケメンです。
タイトルの件、行ってきました。
そして喋ってきました。

もっと違うテーマ選べば良かったな・・・と思いつつも巻き気味でサクッと。

個人的に面白いなーと思ったのが、
@omoonさんの、~素晴らしき Carbon の世界 〜あなたも今日から日時マスター~だった。
関西の方でしゃべりも面白く、余裕が感じられた。

レガシーな環境にいきなりぶっこむと日時判定全部置き換えとかだるいんで、
どっか少しづつ入れたいなと思いました。

総評としてはPHPのカンファレンス初めて行ったんだけど、結構PHPを自虐ネタにしてるのが多くて、
コミュニティとしてその点だけは健全ではないなって思った。

個々人はみんな凄くいい人で気さくだったから、このつながりがもっと広がって
言語コミュニティに属する人が今よりもっと誇りを持っていけると良いなって思ったのでした。
(別に誇りをもってないとかそういう話じゃない)

よく使うコマンドを楽にalias登録する

こんなことないですか。
よく使うのに、
毎回、

cd /hoge/fuga/application/module/class/lib

とか打っちゃうこと。

あ・・・

ない?

あ・・・

ないですか。。。

僕はよくあるんですけどね!!!1

alias使えよっていうツッコミはもっともなんですけど、
いちいち登録するのだるいじゃないですか。

そんなあなたにこのワンライナー。

history | sed -E 's/^ +[0-9]+ +//g' | \
awk '{count[$0]++}END{for(i in count)print count [i],i}' | \
sort -nk1 | sed -E 's/^[0-9]+ (.*)/alias name='\''\1'\''/g' | tail -10 

historyコマンドの出現回数を降順にソートして
aliasコマンドの形式で出力してくれます。

~% history | sed -E 's/^ +[0-9]+ +//g' | \                                                                                                                                                                          
awk '{count[$0]++}END{for(i in count)print count [i],i}' | \
sort -nk1 | sed -E 's/^[0-9]+ (.*)/alias name='\''\1'\''/g' | tail -10
alias name='echo "" > ~/.fk_config'
alias name='knife solo cook php4'
alias name='cat ~/.fk_config'
alias name='cd'
alias name='history'
alias name='konkatu party'
alias name='cd ..'
alias name='ls'
alias name='sake nomitai'
alias name='ls -ltr'

これを~/alias.txtとかに出力して、
nameの部分を任意の別名に書き換え

# /home/alias.txt
alias ltr='ls -ltr'

あとは.bash_profileとか.zshrcsource ~/alias.txtとか追記すれば

~% ltr
total 160
drwxr-xr-x@  9 yamashitakazuhiko  staff    306 Nov  9  2010 framework
drwxr-xr-x+  5 yamashitakazuhiko  staff    170 Jan 16  2011 Sites
drwxr-xr-x+  6 yamashitakazuhiko  staff    204 Jul 13  2012 Public
drwxr-xr-x+  2 root               wheel     68 Jul 17  2013 tmp

aliasが使えちゃいます。
最初LLでラッパーつくろうかななんてことも思いましたが、
コマンドでできることはコマンドでやるのがモットーなので
ワンライナーにしました。

めんどくさがりのそこのアナタ、ご活用下さい。