開発サーバ構築しよう~LDAP(認証基盤)を立てよう~開発サービスはDockerで立てよう
LDAPサーバ立てよう
開発プロジェクト用の開発サーバ構築の一貫として
- SCM(Subbversion, Git)を立てるにしろ
- ITS(Redmine, Trac)を立てるにしろ
- CIサーバ(Jenkins)を立てるにしろ
- モジュールリポジトリサーバ(Nexus)を立てるにしろ
- Wiki(MediaWiki)を立てるにしろ
- コードインスペクション用サーバ(SonarQube)を立てるにしろ
- メールサーバ(Dovecot+Postfix)を立てるにしろ
- 他もろもろを立てるにしろ
大概そいつらにはメンバーごとのログインという共通要件があります。
メンバーが追加されるたびに、手順書を更新していちいち各サービスのユーザ登録手順を増やすのもいいんですが、そういうことやってると、
- 登録・削除が面倒だったり、
- アカウントIDやパスワードがサービスごとブレはじめたり、
大変不便なので、Open LDAPとかで共通のLDAP認証サーバを立てましょう。
LDAPサーバにユーザのアカウント情報や集約され、各サービスがそれを参照しにいくので、全サービスでログイン情報を一元化できます。
また、グループ情報も集約でき、Jenkinsでグループ情報を見て権限を分類したり、メールサーバがメーリングリスト代わりにしたりできます。
本当に手間が浮くか
と言われると、正直のところ微妙です。
RedmineやJenkins、MediaWikiなどよくあるLDAPログインの実装だと、LDAPでログイン成功した瞬間に各サービスにアカウントをオンザフライで作成してくれたりします。
その時アカウントに使うメールアドレスや姓・名、ユーザIDはLDAPから自動補完してくれます。
逆に言うと、LDAPで補えない情報は、そのオンザフライアカウント作成後で手作業でつけろというわけです。
各サービスを拡張して全てLDAPから必要なユーザ情報を拾えるようにするのも大変ですし、どうにかならないかなあとも思いますが、やっぱりLDAPは無いよりあったほうが楽に感じます。
社内のActiveDirectoryとかは使わない
プロジェクトごとにLDAP立てないで、会社で使っているActiveDirectoryにLDAP喋らせてつなげばいいじゃないか的なことを考えるかもしれませんが(あるいはActiveDirectoryと直接つなげるとか)、下記のような例外に対処しづらいと思います。
- 社外の人
- 一時的な人
- マシン用アカウント(私はJenkinsやRedmine用の非人間用のアカウント作成したりします)
プロジェクトと社内メンバーは厳密には違うものです。たとえ社内メンバーがプロジェクトグループに収まっていても、です。
そこのギャップをちゃんと吸収できればアテにしてもいいですが、大概、プロジェクトのコントロールから外れる資産をアテにすると割りとロクでもない結果に繋がりそうだと僕は思うので、自前でLDAP一式そろえることをおすすめします。
増えまくる開発用サービスはDockerで対処しよう
また上記のような開発にまつわるサービスはガンガン増えていくので、Ubuntuなりの上でDockerを使ってコンテナ型で起動することをおすすめします。
Dockerをつかわず、あるOS上に直接いろんなサービスを入れると整理がつかなくなりますし、マシンをわけまくっても費用が高く付きます。
Dockerの上に立てておけば、万が一性能問題とかである開発サービスだけ別サーバに疎開させることになったとしても、簡単に移動・複製ができます。
(僕の場合はnginxでDocker上のHTTPしゃべるサービスにリバースプロキシさせています。)
Dockerのサーバ自体も仮想環境で動かそう
これに加え、Dockerが動くサーバOS自体もKVMといったハイパーバイザー上で仮想ゲストOSとして動かすと小回りが効いて便利です。
(別にKVMじゃなくてもいいです。ESXiなりHyper-Vなりお好きなのをどうぞ。)
仮想環境でOSを動かしておくと、ゲストOSのバックアップ含め、いろんな操作がラクチンになるのでおすすめです。
個人的に思うこと
こういう内部向けの開発サービスの構築って大事なもののはずなのに、非技術系の人が集まると異様に軽視されはじたりします。
ま、そういう人たちには、こういうモノがどういう価値を持つかなんて分からないし興味が無いので、当然といえば当然ですが、例えば最終的に発生したプロジェクト炎上という現象の原因が、結局はプロジェクトマネジメントとか顧客とか宇宙の法則とか、そういった言葉でしか締めくくれないとしたら、こういった要素をあまりにも軽んじているのではないかと思います。っていうかあんたら開発の仕事してんだよね?!
残念ながらそういった人たちが集まる場は多いですが、そういった中でも慎重かつ大胆に構築して、触らせてその価値を体感してもらうことが大事です。
構築ごとにわざわざ承認とったりすると、たぶん認めてもらえないので動く現物ぶつけたほうがいいと思います。
でも、本当のことを言ったら、組織として開発の成果を出すのに一番大事なのは、こういったことを軽視しない風土でしょうね。
少なくとも開発者が片手間にイヤイヤやらされるようなことじゃないと思うのです。