質問: サーバ管理用に使う、スクリプトや設定ファイルは、どのように変更管理してますか。 共用アカウントを使い、本番サーバしか無い状態で、変更管理をする場合は、みなさんはどのように管理されていますか? 私は、社内向けに提供するデータ分析用のサーバの管理及びデータ解析を任される事になりました。 ただ、規模が小さいので、開発-ステージング-本番といったアプリ開発の様な構成も取れず、 直接本番サーバのスクリプトや設定を弄っている状態です。 現状の管理方法としては、同一フォルダにディレクトリを用意して、「~.pl.r1」の様にして過去分を管理しているのですが、これはさすがに色々マズ過ぎと考えています。 また、簡単な構成は下記の様になります。 ログの集約サーバがあり、そこのログで必要な分を、機能ごとに分けた分析用サーバ(複数)はマウントして使用する(どちらのサーバもすべて仮想マシン)。 また、ログの集約サーバには分析用サーバ用の共有ライブラリ(perl、sh)もあり、 各分析サーバはそこをマウントして共用する。 と言った状態です。 私なりの答えとしては、 ログの集約サーバにリポジトリを作成して、各分析サーバはそれをチェックアウトして使用する。 と言うものですが、アプリ屋あがりなので、インフラ管理という視点ではどうなのか検討がつきません。 さらに、githubの様な外部のホスティングサービスは、上司の許可が下りないので、 使えるとしても、subversionやGitLab、GitBucketあたりのオンプレミスなバージョン管理ツールしか使用出来ません。 また、個人情報を扱うログデータもある為、それを加工するスクリプトには、一部の人しか触れないようにロール管理も必要です。 みなさんならどう対応しますか?
回答: 何が課題であるか、説明ごとに論点がズレているようにも感じます。 例えば過去分をリネームで管理していることが課題なのかと思えば、分散サーバにチェックアウト...という話が挙がってくるので、なぜチェックアウトが必要なのか、という疑問が生じてしまうのです。 リポジトリ管理とデプロイは別の話です。 「インフラ管理という視点ではどうなのか」と言われても、共用アカウントで開発環境すら用意できないという前提では、制約の中でしか考えられません(つまりベターですらない)。 読み解ける情報からだけ判断すれば、サーバにリポジトリを作るというのは、「過去分を管理」という観点では正しいと思います。 もし、共有ライブラリ以外のスクリプトも、分散サーバに「コピー」しないといけないと言うのであれば、タグからしてLinuxをお使いのようですから、rsyncでデプロイしてもよいのではないでしょうか。 ロール管理も、現時点でサーバへアクセス権がない人には、引き続きアクセス権がないので問題ありませんし、今は正しくないアクセス権があって困っているというのなら(そうは書いてありませんが)、まずはアクセス権を正しく設定するところから始めないと意味がありません。 gitで履歴を管理するだけであれば、リモートサーバを置く必要はありません。ローカルリポジトリを他と共有するために置く場所ですから、共有する必要がなければ必要ないと思います。 オンプレミスで置くのであれば、今はGitLabが一番容易だと思いますが、サーバは丸一台仮想で用意した方がよいです。Javaを動かすことができるウェブサーバ(tomcatなど)があるのであれば、GitBucketも容易です。jarファイルの設置だけで使えます。 ただし、本番サーバに乗せよう...というなら、いずれにしてもお勧めはしません。 「インフラの観点」からいえば、一つのサーバに何でもてんこ盛りにするのはリスクです。仮想化で運用されているのなら、新しいサーバを立てます。