僕にとって、YAPC::Fukuoka 2017 HAKATAは非常にロングランで濃いものだった。まずは前日に自社のオフィスで開催された、全然野菜に始まる。 これは元々同僚である @hsbt さんが社のSlackで下記の投稿をしたことから全てが始まった。 現在ペパボ@福岡はオフィス改装中で、ペパステというステージを設けて、登壇イベントをパッケージングしているのでほとんど準備することなく飲み物の準備をするくらいで、当日 #全然野菜 がバズるくらいには盛り上がって大変良かった。 YAPC::Fukuoka 前々夜祭(非公式) きた、ペパステという空間がおしゃれ #全然野菜 #yapchttps://t.co/lrA4cM89lL pic.twitter.com/vk1nglSPiE — うずら (@uzulla) 2017年6月30日 その後は公式の前夜祭に移動し、 @udzura が酔って変なテンションになりながらも、Perlと称してClangのライブコーディングをやり遂げるさまを眺めたりしていた。 こんにちは〜 pic.twitter.com/zpXDzk926t — SHIBATA Hiroshi (@hsbt) 2017年6月30日 そんなこんなでLTソンも終わり、 @hsbt と談笑していると、後ろから肩を誰かにぐわっと捕まれ、 「魚っ!おすすめ！」のような検索ワードか！！という勢いで @songmuさんに声をかけられたので、前夜祭のあとは次の日のトップバッターが両方存在するというチキンレースのような面子で鯖郎へ。 これが管理職ですよ — songmu (@songmu) 2017年6月30日 今年もとても良い YAPC だった！ #yapcjapan pic.twitter.com/Mw27xOHh4s — 大沢和宏

More

今年を振り返ると、何と言ってもSTNSだった。STNSのinitial commitは2016/01/03

More

どうも皆さんこんばんは。ナイスガイことカキフライ大好き@pyama86です。 この記事はpepabo Advent Calendar

More

最近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

More

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

More

ペパボでムームードメインの開発運用を担当している@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

More

今日は簡単なシェルスクリプトで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

More

ども。 玄界灘のイケメンです。 9/17に渋谷マークシティのサイバーエージェントセミナールームにて株式会社はてな主催で行われました Mackerel Meetup#5に登壇してきました。 イベントの内容は公式ブログにて紹介されております。 「Mackerel Meetup #5」を開催しました Mackerel is 何 Mackerel（マカレル）は、運用中のクラウドもしくはオンプレミスのサーバにエージェントを1つ入れるだけで、簡単にサーバ管理を始められます。監視サーバ自身の構築・運用は不要です。さらに負荷のリソース状況などの数値をグラフに可視化します。障害発生時にはアラートが記録され、様々なツールに通知できます。システム運用保守に最適な監視ツールです。(公式サイトより) これまでの監視ツール(Zabbix,Nagios)と異なり、設定の主体が被監視サーバであることが非常に特徴的で、 昨今のコード化されたインフラと非常に相性が良いです。 VM起動してプロビジョニングされた時から監視を始めることが出来き、プロキシ環境もサポートしているので 環境の制限を受けることなく利用する事ができます。 僕自身は開発エンジニアをやっているムームードメインを始め、社内プライベートクラウドのNyahのOpenStack基盤にも全面導入しています。 今回僕が登壇した際に喋った内容はペパボでのNagiosから移行する際にNagiosプラグインがそのまま使えて比較的容易に移行できたこと、 自分たちでプラグインを書くことによってあらゆる値が監視可能になったことなど話してきました。 参加者の方々と懇親会で話した限りではまだ導入に至ってない方が多かったことからもうちょっと移行周りの話を濃ゆくすればよかったなぁと反省しつつも、少しでも参考になっていれば幸いです。 感想 今回が東京のイベントで喋る機会として初めてでした。 福岡と比べて懇親会の参加率とかすごく高くて、数名の方に声もかけていただき、非常にアグレッシブでした。 反省はペパボに入ってからあえて名刺持たないようにしていたのですが、割りと名刺持たれてる方が多くて そろそろ作らなきゃなぁと。。。 最も良かったことはナイフのような男だと思い込んでいた@y_uuk1さんが非常に温厚でいい人だったことです。 はてなの方々本当に親切でナイスガイが多かったです。 最後にMackerel本当にいいプロダクトなんで今後もより良くなっていくように上手に使っていきたい、 そして僕らも監視の工数減った部分を上手に使ってより良いサービス作っていきたい。 Samsung Galaxy Nexus (3.43mm, f/2.75, 1/33 sec, ISO125)

More

あるじゃないですか？ 扉とかに 「押」「引」の文字。 僕、常に押すんですよね。 あ、どうもP山です。 Vagrant + chefな環境において限りなく本番環境に近づけたいときに、 NICって結構悩むと思うのですよね。 本番環境はbondingつかってNICを冗長化しているけど、検証だからNIC一個で！が多いとは思いますが、 やってみたのでご紹介。 まずchefにはifconfigというリソースがあって、それを使うとifcfgファイルがDSLで書けるのですが、 そのDSLにMASTERの項目がないので、今のバージョンでは少なくともbondを定義するのは厳しそうでした。 やろうと思うとtemplate(もしくはcookbook_file)でやることになり、それがこんな感じ。 Vagrantfile config.vm.define :compute do |c|

More

ども。 温泉太郎こと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

More