作業環境

2015年03月27日

このエントリーをはてなブックマークに追加

個人作業環境を一撃セットアップ

身近なメンバーに説明する手頃な材料が欲しかったので、本エントリを書いた。

作業ノードを転々としていると、各所に作業環境を構築する回数が多くなる。作業対象が使い捨てである事が増えれば増える程、その傾向が強くなった。構築回数が多いからこそ、整理する機会に恵まれていたとも言う。その結果、今ではログイン後に下記コマンド1行を実行するだけだ。

$ curl -fSkL https://raw.githubusercontent.com/hansode/env-bootstrap/master/build-personal-env.sh | bash

build-personal-env.shの処理を掘り下げて行く。

build-personal-env.sh 処理概要

  1. mkdir -p ${HOME}/repos/git/github.com
  2. hansode/dotfiles${HOME}/repos/git/github.com/に配置
    1. cd ${HOME}/repos/git/github.com/ && make
    2. make 実行により、自分好みのdotfilesが配置・セットアップされる

dotfilesdotfileだけを管理し、env-bootstrapdotfilesをセットアップする。dotfilesにセットアップスクリプトを置いても良いが、役割分担を明確にする為にも別プロジェクトで管理している。今(2015/03/27現在)は、たまたまdotfilesしか扱ってないが、他のプロジェクトを扱いたい場合は、今の様に役割分担してる方が柔軟な管理が可能。かつては別プロジェクトを扱っていた経緯がある。

dotfilesが環境を判定

作業対象は複数あり、プラットフォーム毎に必要なdotfileが異なって来る。

  • Cygwin 1.7 / Windows 8.1
  • MacOS 10.10 (Yosemite)
  • Raspbian 7.6 (Wheezy)
  • Fedora release 20 (Heisenbug)
  • CentOS-6.6/6.5/6.4
  • CentOS-7.0.1406

例えばCygwin環境にはDropboxをインストールしているので、Cygwinのホームディレクトリからアクセスしやすいようにしている。また、CygwinとMacOSでは、Vagrantを扱う事があるので、Vagrant環境を整理している。

自身の${HOME}構造を標準化

build-personal-env.shが配置するdotfileswork/repos/git/github.com/dotfiles配下。これは自分だけのルールであり、第三者に強制されるものではない。長年の経験から程よく管理しやすい構造として辿り着いた構造は、下記の通り。

まとめ

自分が実施して来た手順を整理すると、こうなる。

  1. dotfilesを整理する
  2. dotfilesをセットアップするスクリプトを管理
  3. ${HOME}構造を標準化する
  4. 1〜3を繰り返す

自分は上記順序で整理して来たが、1〜3の順序に根拠や強制力は無い。整理出来そうな所から整理すれば良い。重要なのは、整理する事だ。

関連成果物




編集
@hansode at 19:30|PermalinkComments(0)TrackBack(0)

2011年08月13日

このエントリーをはてなブックマークに追加

サーバを新調する度に幾つものコマンドを実行するのか?

新プロジェクトが発足する度に開発環境が用意される事は、良くあるはずだ。 そして、その度に、使い慣れた環境へと変身させる作業が発生するはずだ。 中には何も設定しない人も居るのだろうか? 何も無い環境だと、どうしても作業し辛い。その要因の大半は、いつもの使い慣れた環境とは違うからだ。

数年前、CodeReposdotfilesとして個人環境設定を登録する流れが発生した。この流れに自分も少し乗っかり、emacsの設定をコミットしてみた。 使い慣れた環境の設定を登録しているだけだったので、その時には気付いていない、新規調達サーバ・開発環境をリプレースした際、素早く環境整理する仕掛けまでは用意していない自分が居た事に。

きっかけは開発環境の移行

Wakame-VDCの開発をアメリカからしてる時の事。アメリカの通信回線の細さに対し次第にストレスを感じ始める。Wakame-VDCの開発環境は、東京事務所内に置いてある物理サーバを使っていたのだ。これまでの開発スタイルは、

  • 開発サーバへSSH接続してログイン
  • emacsでプログラムを書く
  • コマンドラインでコンポーネントを起動・停止

これをアメリカから行っていると、日本の10年以上前のダイアルアップ接続をしていた頃の様な速度になる時がある。YouTubeで動画を見たり、OSのインストールイメージをダウンロードしている時だ。東京に居たら考えられない事が、アメリカの通信事情では起こり得る。

通信状況に不満を覚えた自分は、『手元のラップトップに開発環境を構築してしまえば解消するはずだ。』 そう思い、開発環境移行に着手した。開発に必要となるOSは2つで、UbuntuOpenSolaris。 Windows 7にインストールしたVirtualBoxで仮想マシンを用意し、2つのOSをインストール。ここまでは実に順調だ。しかし、この後だ。開発環境整理が待ち受けていた訳だ。

  1. GitHubにdotfilesを作成、コミット
  2. dotfileをデプロイする仕掛け・・・が無い
  3. デプロイする仕掛けをシェルスクリプトで作り始めた

これらが、スクリプト作成に着手するまでに至る過程だ。

異なるOS、異なるユーザー名に対応させる

OSが2種類あり、作業するUNIXユーザー名も違う。いつも同じユーザー名を使えるとは限らない。 汎用性を重要視し、下記3つの事に注意してスクリプトを書き上げ、Gistに登録した。(※スクリプトのソースコードは、エントリ後半に埋め込んである。)

  • OSに依存しない事
  • ユーザー名に依存しない事
  • ファイルシステムのフルパスに依存しない事

スクリプトを実行しさえすれば、使い慣れた環境の一歩手前、必要最低限の環境が手に入る。 一歩手前なのかは、アプリケーションインストールまでを行わないからだ。

スクリプト化した事により、新環境へ移行せざるを得ない状況になっても一撃必殺で作業が終わる。 細かい制約を挙げると、事前にGitをインストールしておく必要がある訳だが…大した問題ではない。 スクリプト化後は、大幅に作業工数が減った。

ギーク達がどのように個人的開発環境を新規構築しているのかが気になる。 『開発環境構築手順を晒すブーム』が到来してくれないだろうか?

あと書き
変化を好機と位置づけ、それを楽しめ
個人的な環境を構築するスクリプト

この環境は個人使用に特化しているので、万人が使って幸せになれる訳ではない。

詳解 シェルスクリプト
Arnold Robbins Nelson H. F. Beebe
オライリージャパン
売り上げランキング: 95612



編集
@hansode at 15:00|PermalinkComments(0)TrackBack(0)