ハトネコエ Web がくしゅうちょう

プログラミングとかAndroid

letsencrypt renew 後に nginx restart が必要

久しぶりにメモ。

自分で管理してるサイトにアクセスしようとしたら
SSH証明書の有効期限切れエラーを見ることに。

で、なんか設定忘れてるのでは、という気がして他の人の renew のやり方見ていたら、(Let's Encrypt で Nginx にSSLを設定する - Qiita
「nginx再起動してるじゃん!」と気付いたので

sudo service nginx restart

そうすると、ちゃんとHTTPS接続ができるようになりました。

nginx restart させなきゃなのね。

そんなわけで、Ansibleを修正しつつ、サーバーの方でも

sudo crontab -e

で root の cron 設定を

0 4 * * * letsencrypt renew --non-interactive --no-self-upgrade

から

0 4 * * * letsencrypt renew --non-interactive --no-self-upgrade && service nginx restart

に変更しました。めでたし。

これでもまた3ヶ月後にSSH接続できなくなったら悲しいな……(でもありそうだな)

エンジニアが辞めない組織について本気出して考えてみた

いつもは技術系の記事ばかりですが、最近ビジネス書を読んで「なるほどなー」と思ったので、
エンジニアが居続けてくれる組織についてあれこれ考えてみます。

読んだ本↓

まだこの本しか人事本は読んでないので、この本の受け売りが多いです。(他の著者のをもう数冊読まなきゃね!)
あとは自分がエンジニアやっていて感じることからの感覚をミックスして。

0. 本の概要

さてさて、この本の概要ですが、一番言いたいところは
『人の成長なくして企業の成長なし』
ここに尽きると思います。
社員教育にお金と時間をかけられていない会社は、そのうち企業成績が頭打ちになるぞ、と。

社内で優秀な人を生み出せなければたしかに将来的にはそうなりますね。
「優秀な人を外から採ればいい」という考え方もありますが、現在社内にいる人との軋轢(あつれき)が生じたり、
この本にも書かれていますが、他社で業績を上げた人が必ずしも自社でパフォーマンスを発揮できるとは限りません。

それは、なにも転職者が経歴を大きく見せたとかいうわけでなく、
その人が優秀に見えるようにサポートした優秀な人が他社にはいたとか、
優秀な人が満足して働ける下地(社風、上司、資金体制)が自社にはないとか様々な理由があります。

この作者さんの会社は営業マンを育ててるので立場は違いますが、
「成長できない会社に居る意味はない」と考えるエンジニアとは利害関係が一致しそうですね。

「優秀になって会社辞めていく人いるじゃん!」というツッコミはありそうですが、
優秀な人を作らないよりはマシです。
教育をせずに優秀な人を1人も生み出さないよりは、
50人優秀な人を作って30人辞めていくことのほうが遥かに会社の未来が輝きます。
教育を受けたことを実感する人は会社に恩義を持ってくれますので、自社に仕事を持ってきてくれることや、社に再び戻ってきてくれる可能性だってあります。

1. 採用と教育

「辞めない組織」と考えると、職場環境の改善を考えてしまいますが、
そもそも採用に失敗している可能性があります。

たとえば、「優秀な人だけをとる」。
会社立ち上げ時に凄腕エンジニアを2〜3名確保する、というのはいいかもしれませんが、
3名前後揃ってきたなら、会社の理念に共感してくれ、未熟だけど素直でやる気にあふれてる人を1人は採るべきです。

まず、優秀な人は簡単に辞めます。
理由は単純で、優秀だからです。
他に働きどころはいくらでもあります。

そしてエンジニア業界は狭いので、
優秀な人が辞めると「あそこはあんまりいい会社じゃないかも」という印象が生まれます。(退職エントリが書かれることもありますし)

ですので、優秀な人だけをとらず、未熟な人を入れます。

そして、優秀な人達には未熟な人を教育してもらいます。
この教育には様々な効果があると私は考えています。

  • 教える側が、知識の再確認ができ成長できる
  • 人的マネジメントスキルのある人(リーダーに向く人)がわかる
  • 母性本能の目覚め

最後アホなこと書きましたが、男女問わずいわゆる母性本能は多かれ少なかれあると思っていて、
人を育てていると、「この子の面倒は最後まで見なくちゃ」という気持ちが芽生える人がいます。
そうすると、優秀な人であれどその職場で働く特別な意味というのが生まれ、長く居着いてくれる原因につながる可能性があります。

この、「職場で働く意味」というのはとても大事で、
本の中ではコミュニケーションを密にすることで『職場が居場所の1つになっている』ことが辞めない環境づくりの1つの策だと書いてありますが、
優秀なエンジニアの居場所は多いです。ネットや他社との付き合いなど、居場所はありますしすぐに作れます。

自社で働く意味を持たせられる組織づくりがあるなら積極的にしていくべきでしょう。

教育する側と教育される側の密な関係がある組織というのは、
フリーランスをするよりも会社で働くほうがいい」と思わせる大きな効果が望めるでしょう。

エンジニア人事としては、教育する側と教育される側のバランスが悪くならないよう、採用に気を付けるのもそうですし、
教育される側だった人が教育する側に回れるタイミングを見つけられるよう、教育する側の人たちのフィードバック、
教育する側に向いている人を知るために教育される側の人たちのフィードバックをとるなど、
各エンジニア間の相互フィードバックを見られるシステムづくりをしておくことも大事になります。

2. 優秀になる人を採る

さて、先ほど「会社の理念に共感してくれ、未熟だけど素直でやる気にあふれてる人」と書きました。

会社の理念に共感してくれる人を選ぶのは、長く居てもらうためです。
社長の考え方と大きくかけ離れている人は、いずれ会社の方針との衝突を起こします。
しかもプログラマーはロジカルに考えられる人が多いので、その人の意見にも筋が通っていたりして困ります。

これがコミュニケーションが密な職場で、かつ、社長と対等に話し合える職場であればいいのですが、
そうでない場合は新入社員の不満はどんどん溜まっていき、「いつか辞めてやる……」とストレスを抱えていきます。
社長は強い意志をもって方針を考えているわけで、それを簡単に曲げるわけもないので、人事としては会社の方針に共感してくれる人を優先的に採用するのが無難でしょう。

イエスマンだけ採用しろ」と書いてるみたいで自分でも書いてて気持ち悪さはあるのですが、
ただ、会社の向いてる方向と違う方向を向いてる人が多くては会社はいっこうに進みませんし、
社長目線としては、会社の方針をしっかり理解してくれているポストがいなければ社長が抱えている業務を安心して任せられません。
そういうわけで、全てにイエスである必要はもちろんありませんが、会社理念には同意してほしいかな、というところです。

次の素直でやる気にあふれる人については、単純ですね。
教えがいがあるからです。

教える側になる人たちは教えることの専門家ではないですから、
モチベーションが保てなくなれば放棄します。
モチベーション維持となるのは、やはり結果が見えることです。

ですので人事は、教えがいのある人を採用してくるのが大切になりますし、
教える側の上の立場の人は、新人の成長を本人だけでなく教える側の人にも伝えてあげてください。
子どもの成長が褒められるのは、親として当然うれしいことです。

そして、素直でやる気にあふれる新人は、速いスピードで教える側へと成長を遂げてくれることでしょう。

3. 不満のキャッチアップ

この本……えっと、間が空いてしまったのでもう一度貼っておきます。この本ですね。

この本でこのような記述があります。

コミュニケーションが足りない職場では、最初は小さかった不満の種が、放置されることによって日に日に増幅していく。
その結果、「どうせ誰も自分を気にかけていないのだから、我慢する必要はない」と辞めてしまう。
十中八九、このパターンです。

> それな <

という気持ちです。

本当にこれです。
別れるカップルと同じです。

不満へのケアが足りていないと、しだいに「不満あつめ」をしだします。
最初は「△△がイヤ」という不満だったのが、
時間が経つと「△△がイヤだし、▽▽もいけてないし、××もダメ」とどんどん嫌なことが目についていきます。

友達に相談したら当然「えー、それならもう辞めちゃいなよ」ということになりますし、
自問自答でも「辞めるしかない」という結論に達するので、辞職の意志が固まります。

辞めることを決意したあとでは、それの理由付けのためにますます「不満あつめ」は加速していきますし、
その状態ではもう上司の「辞めないでよ」という声は厚い壁に阻まれてちっとも届きません。

辞職願を出されてからではもう遅いのです。
大切なのは、常に不満へのケアが出来ることです。
必ずしも改善まで結びつく必要はありません。聞いてあげるだけでも大きく違います。

では、不満を常に言ってもらえるようにするにはどうすればいいかという点については
密なコミュニケーション。これに尽きると思います。

本の中では質も大事だけどそれ以上に量が大事としており、
上司が部下とのコミュニケーションを積極的にとるような仕組みづくりについても触れられています。

本の中では飲みニケーションを仕組み化している点が記述されていますが、
なにもお酒を飲むことに限らず、(飲めない人もいますし)
おいしい料理を食べることや一緒にゲームをすることでも気はゆるみますので、
そういう機会を多く設けることが有効でしょう。

社内の人とのランチ補助制度や、部活制度を設けてる会社がありますが、
こういう狙いだったんだなと気付き感心しました。

『優秀な技術者を追い出してしまう方法』という記事がありましたが、
これらは具体的すぎる内容でどの会社でも等しく起こる問題ではないですから、
会社としてまずおこなうことは、コミュニケーションを密にして上司が部下の不満を常にキャッチアップできる環境づくり、というところでしょう。
その上で、記事にあるような不満が出てくるかもしれませんが。

コミュニケーションの数、そして、気がゆるんでなんでも話せる場(お酒だったりおいしい食事だったりゲームだったりがある場)の用意、
あとは「最近なんか困ってることある?」と聞くようにすれば、自然と不満をキャッチアップできるようになっていくことでしょう。
最初は部下は遠慮するでしょうが、回数を重ねて少しずつ壁がなくなればよいかと思います。

4. おわりに

以上、『辞めない採用、即戦力の育成で儲かる会社になる!』(著:小山昇)を読んで
自分なりにまとめてみた意見でした。

この本とても良くて、1000円ちょっとで買えるのに、

  • 新卒採用・中途採用における人の選び方
  • 新卒へのアピール方法
  • 新卒採用の教育手法
  • 中途採用の注意点、教育手法
  • 社員に長く居てもらうための仕組みづくり

など、網羅的な人事の考え方を実例とともに読みやすい文体で書いてあって良書だなと感じました。

もちろんあくまで一人の考え方をまとめた本なので全てを鵜呑みにするのは良くありませんが、
なかなか説得力のある発言にあふれていました。

エンジニア採用の現場ではよく「優秀な人(=即戦力を指す)に来てもらいたい」なんて声を耳にしますが、
本当にそれでいいの? 新人教育って必要ないの? など考えるところはいくつかあったので、今回の記事で考えをまとめられてよかったです。

話の流れで入れられなかったのですが、私の考える「優秀な人」は情報共有の出来る人です。
どれだけプログラミングが出来る人でも、会社は組織立って動くところですから情報共有をしてくれないと困ります。

勝手に実装進めてたけど、他の人がプルリク見て初めて、急ぎでない用件のほうを実装してたことがわかるとかは困ります。
なにも情報共有されていないと、その人が辞めたあとによくわからないコードの山が残ります。

逆にプログラミングが多少できなかろうと、悩んでいることを共有してくれるのなら周りはアドバイスができます。

どうしたら情報共有の出来る人って採用できるんだろうと考えちゃいますが、
ひとつは伝達力を測ることでそれを望めるのかなと思ったりはします。
たとえば「バナナとはなにか説明してください」のような、ふだん説明しないようなものの説明を、
多すぎないしゃべりで、的確に表現できる人は情報伝達力が高いなと感じます。

いろいろ考えてみましたが、
人事というのはなかなか最適解がなくて、プログラマーよりよっぽど難しい職業のようです。大変面白いですね。

プログラマのための数学LT会 2! 開催しました

プログラマのための数学LT会 2!

ふたたび主催やらせていただきました!

プログラマのための数学LT会 2!』 です。
https://techplay.jp/event/624044

場所は dots. あらため TECH PLAY さんで開催させていただきました。

2回目ですが、1回目開催の時は開催の疲れから
ブログを書いている余裕がなくて書いていませんでしたので、この記事では
1回目開催に至った経緯なども書いていきます。

f:id:nekonenene:20170723022409j:plain

1. まずは今回の反省から

たくさんの人から「タイムキープちゃんとして!」って怒られました。ごめんなさい。
前回、全員が15分で発表を終えるという奇跡的な進行を見せていたので
「まあ、なんとかなるだろう」と甘く思っていたところはあります。

胃がキリリとなるくらい反省したので、
次回はちゃんとカウントダウンを見せるためのタブレットを持ってきます。

あと、15分は短いですね!
皆さんが今回くらいの資料作ってくださるなら、持ち時間はもうちょっと欲しい!
次回は一人の持ち時間20分以上になる予定です。

2. なんでこのイベントを始めたか

そこそこ聞かれるのでまとめておきます。

もともとは、Yahoo!の佐野さんがやっていた プログラマのための数学勉強会 というイベントがありまして、
「これはおもしろいイベントだ」と、私もそこでLT枠で参加させていただいていたんですよね。

ただ、2016年3月の第6回以降、佐野さんが大学院に入ってしまって、なかなか忙しくて、
当初は半年後に開催する予定(と言っていた気がする)だった数学勉強会が開催されず、
「あ~~~発表したいのに無いのかな~~~」と思っていて、
「よし、じゃあ自分がヒマ人だしやるか!」という気持ちになってきました。

誰もやらないなら自分がやるべき!という信条で生きてるので、やるか! と。

とはいえ、何もわからないところから始めるのは不安しかなかったので、
12月に佐野さんに連絡して、2月にお話を伺う機会をいただきました。
それでその後、TECH PLAY(当時はdots.)の担当さんといろいろFacebook Messenger上でやり取りし、開催にこぎつけました。

それが2017年3月におこなわれた1回目のイベントになりました。
で、そのときに「次回は3ヵ月後くらいに」と言ってしまったので、(正直負担もあるので開催に踏み切る決心が大変でしたが)今回の2回目になりました。

2回目開催を決心したときは、「これで最後にしよう」と90%くらい心に決めていたのですが、
いい登壇者の方々がどんどん集まってくれて、「あ、これは3回目もやろう」と急に気持ちが変わりました。
本当に参加者の集まりが心の支えです。

3. 数学は得意なの?

ってことも聞かれるのでついでに書いておきます。

お恥ずかしいことに、大学数学まったくわかりません!

とはいえ、プログラマのための数学LT会に参加されるプログラマの皆さんもほとんどそうなので、
きっと問題ないかと最近は思ってます。

中学高校の頃の数学は得意でしたが、特別好きでなくて、それよりも小学生算数が好きで、
「数学より算数が好き」と中学生当時はよく言ってましたし、小学生算数が一番おもしろいという考えはいまだに変わってないです。

37 × 3 = 111
になるってことは
37 × 27 = 999
ってことで、それすごくない?! とか思ってます。

しかも
37 + 27 = 64
なんですよ?! 2の6乗ですよ!

さらにさっき気付いたんですけど、
37 ÷ 27 = 1.370370370370……
なんと 37 が何度も続くのです!

37と27の組み合わせなんて、見た目は気の難しい頑固者同士みたいな組み合わせなのに、
二人の生み出すパフォーマンスがあまりに華麗すぎてため息が出てきますよね。

そういうのが好きなので、数学が好きというよりは、数字と平面図形に魅力を感じているのだと思います。
行列の計算とかは勉強ととらえてる節があるので、
今回の数学LT会のように「行列はこんなことに使える」をもっと聞いていると考えも変わってくるかもしれません。

4. 今回のイベントについて

だいぶ違う話が長くなりましたが、
プログラマのための数学LT会 2!』 の感想を。

私のはぼんやりした感想ですので、以下の記事のほうがよくまとまっています。

ブログまとめ枠として参加くださいました「まえすとろ」さんの記事
http://lyricalmaestrojp.hatenablog.com/entry/2017/07/20/012502

Togetterのツイートまとめ
https://togetter.com/li/1131615

LT 1 : プログラマのためのトポロジー入門 〜 山手線は丸いのか? (佐野 岳人)

「到着が19時よりちょっと遅れるかも」と連絡来たときは「お気をつけてー」と思うも、
「いや、佐野さんトップバッターじゃん!!」と気付いて慌てました(笑)

結局19時より数分前に到着してよかったです。

www.slideshare.net

けっこうわかりやすいトポロジーの発表でした。
おもしろくて、のめりこんで聞いてたのはよかったんですが、
「時間大丈夫ですか?」と佐野さんに聞かれたときにはすでに15分経過してて「あっ」って思いました。

開会式での会場の反応悪くてけっこう落ち込んでた時間だったので、時間ちゃんと見てなく……。

せっかくプログラム作ってきてくださったのに、デモをおこなう時間がなくて申し訳ない気持ちでした。
でも67ページあるスライドは15分じゃ終わらないよ!佐野さん!(笑)

LT 2 : 計算するということ (おおとや)

前回のアンケートで「難しすぎる」という感想をたくさんいただいてしまったので、
「次回はわかりやすいものを作ってきます」と意気込んでたおおとやさんの発表でした。

前回のように数学に偏らず、プログラミングも関連する話になっていて
会のテーマにも合っていて、いい発表だったなぁ、と私は思いました。

チューリングマシーンは、チューリングマシーンが無限ループにおちいってしまうプログラムをあらかじめ計算できないのだなあと。

speakerdeck.com

こちら側の裏話として、受付に抜けがあったのか、
出欠管理システム上では、おおとやさんがまだ会場にいないことになっていたので、
佐野さんの発表中、「え! 次の発表者まだ来てない!! 次の人どうしよう…」とすごくあせってました…、
で、よく会場を見渡してみるとおおとやさんがいたので安心しました。

今考えると、おおとやさんだからよかったけど、
私との面識ない発表者さんだったら、「よかった、いる…」とならないので、よりいっそうパニくってたと思います。

LT 3 : 四則演算で描くドット絵 正N角形 (荒木義明)

「小学校算数だけで円周率や三角関数が出せる! かんたん!」みたいな調子で話すも、
それを求めるためにマクローリン展開など出てきて、
「たしかに四則演算(足し算引き算かけ算わり算)だけで出せるけど、それに至る原理が小学生にわからないw」
というツッコミオーラが会場内にあふれていて、
荒木さんの「ね! 小学生にもかんたん!」という調子に会場が爆笑に包まれていました。

でも、娘さんがフィボナッチ数列をソラで言えるようになっているそうなので、案外ほんとうに簡単の可能性も・・・

LT 4 : ゆるふわ情報幾何学 (YE)

最初の導入あたりはよかったかと思うんですが、話の飛躍が多くて、
今まで話していた内容とどうつながっているのかわからないような話の展開になることが多く、
だいぶわかりづらい発表になってしまっていたかなと思います。

また、「これは高校数学の範囲内じゃないので省きます」とやると、ただの穴あきで話が進んでしまうので、
わかりづらくても概念だけでも触れておかないと、結局その後の話が理解できなくなって
誰にもわからない発表になってしまいますので、ある程度は説明を入れると良いと思います。

『高校数学までの知識でもわかる発表内容になっていますとありがたいです』とイベントページにはありますが、
決して高校数学外のことを説明しないでと言っているわけではないですので、
ある程度わかりやすく噛みくだいていただけますと幸いです。

「情報幾何学」というものが何か、をまず知らない人が多いので、そこのさわりを触れて、
それが機械学習とどう関連してくのか概念的なところにフォーカスを置いて語ると、参加層の反応がよかったのではと思います。
(「へぇ~、なるほど、情報幾何を学んでみるか」という気持ちになった人が出たと思います)
テーマがよかっただけにもったいないな、ととても思っています。

LT 5 : 有理ホモトピー論とコンピュータ (若月駿)

難しい発表になるだろうなーとテーマから推測していましたが難しかったです(笑)

内容忘れてるところ多いので、スライドが上がってきたら感想追記しようかなと思ったり…

LT 6 : プラレールでつくる論理回路 (Akama Hitoshi)

Developer Summit 2017 でお会いして、
そのときにプラレール論理回路の実物を見て感動して「ぜひ発表を!」とお願いし、
そして今回でその夢が叶いました。とても満足です……。

speakerdeck.com

発表も上手くて、参加者からの皆さんからの反応もとても良くて、ほんとう登壇してくださってよかったです。
次回は オープンソースカンファレンス2017秋 で実物を見られるそうですよ!

最近はマルチスレッドのプラレール回路を作ろうという構想があるものの、
お金と組み立ての時間が厳しいとのこと……。クラウドファンディングやってほしいです……w

LT 7 : 行列の固有値固有ベクトル (根上春)

www.slideshare.net

とてもわかりやすいスライドを作ってくださいました。

まず行列の固有値固有ベクトルの求め方を話したあとに、
それがプログラマの現場でいかに役立つかという丁寧な説明でした。

残念なことに、前半の、求め方について解説する部分でけっこう時間を使ってしまったので、
後半の一番のおもしろい部分であるプログラミングと行列との関わりについて
あまり時間を使えなくなってしまったのが残念でした。

あと、行列を扱う発表は今回たくさんあったので、
根上さんの発表を1個目に持ってくればよかった~! ってけっこう後悔してました。

いやぁ、いいスライドでしたね……。
プログラマのための行列」とか、そんな感じの本を出してほしいですね。

LT 8 : そろそろ数式お絵描きの話でもまとめておくか (鯵坂もっちょ)

https://www.desmos.com/calculator/vypskkl2vd

参加した人が難しい印象を数学に残したまま帰ってほしくなかったので、
このイベント最後の発表は、できるだけ誰でもわかるようなもの。というのは決めていました。

そういうわけで、エンターテイナーもっちょさんの発表なら間違いない!
とトリに入れさせていただきました。
結果、大正解で、会場の皆さんが楽しんでくださり、とても嬉しかったです。

もっちょさんがTwitterに数式お絵かきを上げているのを何度も見ることはあっても、
どういう手順で作っているのか見ることはなかったので、
「なるほど、最初に描きたい絵を用意して、そこに合わせて図形を用意するのか!」っておもしろかったですし、
「desmosは数学わかってる人が使うもの」みたいな先入観があったので、
全然そんなことないじゃん、気軽に使っていいんじゃん、って知ることができました。華のある発表でした。

5. 今までのアンケート結果

最後に、登壇者へのフィードバックになればと、みなさまからお答えいただいておりますアンケートの集計結果を一部公開します。
この集計作業、 1.5 ~ 2.0 時間くらいかかっていて、けっこう負担かかるので、
次回はアンケート用紙の代わりに、アンケートフォームへのQRコード短縮URLが書かれた紙を配ろうかなと考え中です。

継続的にやっていくためには、負担をできるだけ少なくできると次回開催への精神的抵抗が減るかなと…。
会場押さえたらあとは当日の会場設営・撤収だけで済むのが理想だなと……。

プログラマのための数学LT会(第1回)

f:id:nekonenene:20170723051231p:plain

f:id:nekonenene:20170723051241p:plain

f:id:nekonenene:20170723051248p:plain

f:id:nekonenene:20170723051253p:plain

f:id:nekonenene:20170723051258p:plain

f:id:nekonenene:20170723051303p:plain

f:id:nekonenene:20170723051310p:plain

f:id:nekonenene:20170723051314p:plain

プログラマのための数学LT会 2!

f:id:nekonenene:20170723051805p:plain

f:id:nekonenene:20170723051812p:plain

f:id:nekonenene:20170723051821p:plain

f:id:nekonenene:20170723051828p:plain

f:id:nekonenene:20170723051833p:plain

f:id:nekonenene:20170723051838p:plain

f:id:nekonenene:20170723051843p:plain

f:id:nekonenene:20170723051848p:plain

参加者の方々はこれを見てもらうとわかると思うんですが、
「むずかしい」と思った発表はみんな難しいと思ってます。
一人だけが出来ないわけではないので、安心してください。落ち込まないでください。

そして、わからないことは適宜質問していいと思います。
今回の場合ですと、おおとやさんの「停止性問題」のところとか、
説明されるとわかるけど、そのまま先に進まれると先のところも同時にわからなくなる、みたいなものでしたので、
「そこもうちょっと説明を」と思ったら気兼ねなく聞いてみていいと思います。

とはいえ、今回の15分という発表時間ですと、
割り込んで質問を入れたら全然15分じゃ足りなくなっちゃいますから、
発表の持ち時間は次回はもっと長くしますね!

登壇者の方々は、「ちょうどよい」が50%を下回っていかないよう、
うっかり専門用語の説明を省いていないかなど、
参加者層に数学専門家でなくプログラマが多いことに気を付けてスライドを作るとわかりやすくなっていくかと思います。

以上、主催者として振り返る『プログラマのための数学LT会 2!』の感想でした。
まだまだ主催経験少なく不慣れですが、次回をよりよいものにできるようがんばりますので、
今後ともみなさまどうぞよろしくお願い致します。

Ansibleで、サーバー上の特定ディレクトリにあるファイル名一覧を取得する

個人のサーバーでgit運用したくて、Gitbucket を立ててるんです。
それで、この前 Gitbucket の更新をするときにプラグインファイルも更新をかけたのですが、
困ったことに、プラグインをダウンロードするだけのAnsibleタスクだと
古いバージョンのプラグインファイルもディレクトリに残ってしまってバグるんです。

なので、古いプラグインファイルを削除するためにどうしようかと考えて、
ダウンロードするプラグインファイル名一覧と
現在サーバーにあるプラグインファイル名一覧を比較して、それが異なる場合には、
ダウンロード前にサーバー上のプラグインディレクトリを一度削除することにしました。

やり方が少しややこしいのでここに書き残しておきます。
(Ansibleで配列を扱うのは苦労が多いので、AnsibleでがんばるよりはFabricなりCapistranoなりでデプロイを別におこなうのが本当は健全)

1. もともとのタスク構成

こうなってました。

- name: create plugins directory
  become: true
  become_user: "{{ main_user_name }}"
  become_method: sudo
  file:
    path: "{{ gitbucket_plugins_dir }}"
    state: directory

- name: download plugins
  become: true
  become_user: "{{ main_user_name }}"
  become_method: sudo
  get_url:
    url: "{{ item.url }}"
    dest: "{{ gitbucket_plugins_dir }}"
    mode: 0755
  with_items: "{{ gitbucket_plugins }}"
  notify: restart gitbucket

変数 gitbucket_plugins は以下のとおりです。

gitbucket_plugins:
  - name: emoji
    url: https://github.com/gitbucket/gitbucket-emoji-plugin/releases/download/4.4.0/gitbucket-emoji-plugin_2.12-4.4.0.jar
  - name: gist
    url: https://github.com/gitbucket/gitbucket-gist-plugin/releases/download/4.9.0/gitbucket-gist-plugin_2.12-4.9.0.jar

そしてサーバー上には path/to/plugins/ ディレクトリに以下のファイルが入っているとします。

gitbucket-emoji-plugin_2.12-4.4.0.jar
gitbucket-gist-plugin_2.12-4.8.0.jar

このままタスクを実行すると、path/to/plugins/ ディレクトリには

  • gitbucket-emoji-plugin_2.12-4.4.0.jar
  • gitbucket-gist-plugin_2.12-4.8.0.jar
  • gitbucket-gist-plugin_2.12-4.9.0.jar

が存在してしまい、バージョン違いのプラグインが同居して挙動がおかしくなってしまう。そういうわけです。

2. map で解決

そういうわけで、create plugins directory の前に以下のようなタスクを定義することで解決させました。

- name: check current plugins
  become: true
  become_user: root
  find:
    path: "{{ gitbucket_plugins_dir }}"
  register: current_plugins

- set_fact:
    current_plugins_list: >
      {{ current_plugins.files | map(attribute='path') | map('basename') | list | sort }}
    install_plugins_list: >
      {{ gitbucket_plugins | map(attribute='url') | map('basename') | list | sort }}

- set_fact:
    is_gitbucket_plugins_updated: >
      {{ current_plugins_list != install_plugins_list }}

- name: remove plugins directory (when plugins updated)
  become: true
  become_user: "{{ main_user_name }}"
  become_method: sudo
  file:
    path: "{{ gitbucket_plugins_dir }}"
    state: absent
  when: is_gitbucket_plugins_updated

強引な力技ですね・・・(笑)
では、内容を説明していきます。

まず check current plugins にて find を用い、その結果を変数 current_plugins に渡します。

current_plugins.files は、サーバー上のプラグインディレクトリにあるファイルすべての stat を配列で持ちます。

[
  {
    'path': 'path/to/plugins/gitbucket-emoji-plugin_2.12-4.4.0.jar',
    'mode': '0755',
    'size': ...後略
  },
  {
    'path': 'path/to/plugins/gitbucket-gist-plugin_2.12-4.8.0.jar',
    'mode': ...後略
  }
] 

欲しいのはファイル名だけですから、配列の各要素に対してキー名を指定してそこだけ取り出します。
それが map(attribute=‘path’) の部分です。

この Filter をかけることで、配列は以下のようになります。

[
  'path/to/plugins/gitbucket-emoji-plugin_2.12-4.4.0.jar',
  'path/to/plugins/gitbucket-gist-plugin_2.12-4.8.0.jar'
] 

そしてこの path からファイル名の部分だけ取り出すため、
Ansible側で用意されている basename Filter を使います。

map と組み合わせることにより、各要素に対して basename Filter をかけることができ、配列は以下のようになります。

[
  'gitbucket-emoji-plugin_2.12-4.4.0.jar',
  'gitbucket-gist-plugin_2.12-4.8.0.jar'
] 

そしてその後に list Filter をかけます。
さっきまで『配列は以下のようになります』と書いていましたが、実際には map Filter が返すのはmapオブジェクトなので、
list Filter をかけなければ配列にはなりません。

最後に、sort による辞書順の並び替えをしておいて、
このあとの配列の比較に備えます。
この配列を変数 current_plugins_list として保存します。

ダウンロードする予定のプラグイン一覧にも似たような処理をかけて
変数 install_plugins_list に配列を保存します。

そしてこの2つの変数の値が異なるときは
変数 is_gitbucket_plugins_updated は True となり、
サーバー上のプラグインディレクトリの削除がおこなわれる。という仕組みです。

3. 感想

だいぶ無理矢理やってて、魔術じみてますね。
Ansibleで配列使うのはしんどいですが、こういうことができるんだなーと思って書きました。

もう少しがんばれば、プラグインフォルダーを削除するのでなく、
不要になったプラグインファイルだけを削除する、というふうに書けそうな気がしますが、
中途半端なところで妥協しています。

個人サーバーなので複雑なことしたくなくて、アプリケーションの展開までAnsibleにやらせてますが、
結果Ansibleのレシピが複雑になってるので、ちゃんとデプロイツール使ったほうがいいなという気がしてくるこの頃です……。