スレッドセーフなmruby-signal-threadを書いた

最近仕事でmrubyを触り始めて、だいぶC言語に触れ合う時間が増えてきたので、@matsumotoryのススメもあって、mgemを書きました。 なぜ作ったのか mrubyには既にmruby-signalというCRubyのクローン実装のmgemも存在するのですが、マルチスレッドでの動作を考えた場合に、グローバル変数にmrb_stateを持つことから、意図しない動作となるケースがあるため再実装しました。シングルプロセス、シングルスレッドで使うにはmruby-signalで十分なので、今回はコントリビュートではなく別実装とした意図があります。 使い方 シンプルにこのような実装にしました。mruby-threadにシグナルを指定可能にしたようなイメージが近いと思います。 工夫 実装するにあたり工夫が必要だったのは、下記のコードです。 今回の実装はSignalThread#trapが実行されるごとに、mruby-threadを利用して、そのシグナルを処理する専用のスレッドを起動し、スレッドでsigwaitするような実装としています。しかし、その場合、複数のスレッドを起動した場合に、先に起動したスレッドに後続のスレッドが処理するはずのシグナルが配送されてしまう事が起こりえます。 HUPを処理するスレッド1を起動 USR1を処理するスレッド2を起動 USR1シグナルを送る この場合に、スレッド1にUSR1が配送されてしまうケースに該当します。スレッド1のsigwaitはHUPのみを待ち受けているのですが、そこにUSR1が配送されても意図したハンドラ処理を行うことが出来ません。この辺のシグナルの流れは同僚の@harasouが書いたLinux

More

SSHのログイン先でも最適化されたvimが使いたい

サーバでオペレーションするときに、ちょっとトラブルシュートしたりするくらいならよいのですが、定期的にログインして作業するサーバがそれなりにあって、その生産性があまり無視できなくなったのでSTNSにstns-setupという機能を設けました。 STNS導入済みのクライアントでstns-setupコマンドを実行すると、事前に定義しておいたコマンドを実行することが出来ます。 $ stns-setup アトリビュートはこんな感じです。 [users.example] id = 1000 name = "example" setup_commands = [ "git clone https://github.com/pyama86/dotfiles.git /home/example/dotfiles", "/bin/sh

More

STNSが単体でのTLS暗号化&クライアント認証に対応しました

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-09-22-22-54-23

先日STNS,libnss-stnsともに0.2.2をリリースしました。主な変更内容は下記のとおりです。 TLS暗号化に対応 TLSを利用したクライアント認証に対応 retry_requestパラメーターでクライントのリトライ回数を指定可能にした ubuntu14.04における再起動が完了しない不具合を修正 TLS関連 これまではnginxなどと組み合わせてTLS/SSL暗号化を提供していましたが、@naoto_gohkoさんからissueを頂いたのと、昨今みんな出来るだけサーバ立てたくないんだろうなぁというフォースを感じたので、単体でTLS暗号化に対応し、サーバ、クライアント共にパラメータを追加しています。 STNS.jp Configuration tls_ca = "keys/ca.pem" # using only client authentication tls_cert = "keys/server.crt" tls_key = "keys/server.key" クライアント、サーバいずれもパラメーターの内容は一緒ですが、サーバのtls_ca及び、クライアントのTLS関連のパラメーターについてはクライアント認証を行うときだけ指定してください。 TLS暗号化だけを利用する場合 stns.conf tls_cert = "keys/server.crt" tls_key = "keys/server.key" libnss_stns.conf api_end_point = ["https://example.jp:1104/v2"] TLSクライアント認証を利用する場合 stns.conf tls_ca = "keys/ca.pem" tls_cert = "keys/server.crt" tls_key

More

~/.ssh/configを分割管理できるpincというコマンドを世に産んだ

初夏が猛暑!皆様いかがお過ごしでしょうか? 昨今、サーバインフラのクラウド化により一人のエンジニアが複数のサービスのサーバに対してSSH接続することも多くなってきました。また多くのサーバでグローバルIPを保つ必要がなくなり、リバースプロキシを置いて管理する構成が増えてきたように思います。そこで悩まされるのが~/.ssh/configの管理じゃないでしょうか? ファイルが500行くらいになったり、新しいエンジニアが入るたびに 「xxxに接続したいんですけど、繋がらないんですよぉ~」 「なっぁぁぁにぃぃぃ~~~~!?この内容を~/.ssh/configに黙って書いてくれ!!!1」 なんてやり取り多いですよね。。そういったやり取りをなるべく少なく出来るようにGolangでpincというコマンドを開発しました。 インストール OS Xで利用することが多いかと思いますのでhomebrewを準備しています。 $ brew tap pyama86/pinc $ brew install pinc 使い方 $ pinc init initコマンドにより~/.ssh配下にconf.dディレクトリ、pinc.yml、base_configファイルが作成されます。 conf.d 配下に作成されたディレクトリ、ファイルを再帰的に読み込みます。 pinc.yml includeディレクティブ配下に配列でファイル、ディレクトリを定義すると再帰的に読み込みます。 base_config ~/.ssh/configをコピーしたファイルです $ pinc gen initファイルで作成、定義されたファイルをマージし、~/.ssh/configファイルを作成します。 便利な使い方 複数サービスを提供している会社の場合、~/.ssh/pinc.ymlに下記のように定義することで、複数サービスの~/.ssh/configを一元管理できるようになります。 include: - /path/to/ServiceA_File -

More

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

issue

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