Roswellで使ってみる
色んなプログラミング言語を遊びで触ることが多いのですが、Common Lispもやっています。
日本でCommon Lispとういうと八発白中というブログですが、そこで紹介されていたRoswellというプロダクトを使ってみました。
インストール
$ brew tap snmts/roswell $ brew install roswell
処理系をインストール
ruby でいうrbenvのように処理系をバージョン指定してインストール可能らしい。 とりあえずいまはバージョンどうでもいいので処理系のみ指定してインストールする。
$ ros install sbcl
Repl起動
ros run コマンドでreplが起動出来る。
$ ros run * (+ 1 2 3) 6
雑感
CommonLispを始めるときに処理系をインストールするのは結構面倒だったので、こういうツールはありがたいです。 (まあ、いうほどLisp書いてないけど・・
windows7でvagrant ssh コマンドが使えるようにする
はじめに
windows7でvagrantを使うの続きの記事です。
もしvagrantのインストールがまだであればwindows7でvagrantを使うを試してみて下さい。
vagrant sshとは
vagrant sshとは、vagrantで立ち上げた仮想環境にsshで簡単にログインできるコマンドです。しかしWindowsではデフォルトでsshクライアントが入っていないため、このコマンドが使用出来ません。
このままでは辛いので、どうにかしてwindowsでもvagrant sshが使えるようにします。
mingw-getをインストールする
Windows上でGNU/Linuxのコマンドラインツールを使えるようにしたMinGWというものがあります。 mingw-getとはMinGWのパッケージ管理ツールのようなもので、これを使ってsshをインストールして使えるようにします。
mingw-getはここからmingw-get-setup.exeをダウンロードして、そのファイルを実行するとインストールが開始します。
インストールの手順は、ここも説明に従って行えば問題ないです。
インストールが完了するとMinGW Install Managerが起動されます。
MinGW用にPathを通す
MinGWでインストールされるコマンドなども環境変数Pathを通さないと実行できません。 なにも変更せずにインストールしていればC:\MinGW\binにコマンドをインストールされるのでこのパスをユーザー環境変数Pathに設定してください。
MinGWを使って基本ソフトウェアをインストールする
MinGWを使ったインストール方法はこのブログの詳しく乗っているので、このブログの「パッケージのインストール:GUI編」を参考にしてください。
MinGWでsshクライアントをインストールする
MinGW Install Managerを開いて右側にあるMSYSをクリックするとMSYSのパッケージがリストで表示されます。その中にmsys-opensshとmsys-opensslというパッケージがあるのでそれらにチェックをいれます。
その後、左上メニューのInstallation->Apply Changesをクリックするとインストールが開始されます。
注意点
MSYSのパッケージはデフォルトだとC:\MinGW\msys\1.0\binにインストールされます。ここにもPathを通さないとコマンドが実行できないので、ユーザー環境変数PathにC:\MinGW\msys\1.0\binを追記してください。
vagrant sshを試す
sshのインストールが完了しましたら、コマンドプロンプトを立ち上げ、Vagrantiflleがあるディレクトリに移動します。 そこでvagrant upでvagrantを起動し、vagrant sshコマンドを実行します。
そこでエラーが発生せずに仮想環境の中にログインできたら成功です。
さいごに
vagrant ではrsyncコマンドも使うのでsshと同じ要領でrsyncコマンドをインストールしておいた方がいいです。 ちなみにsshと同じようにMSYSにパッケージが入っています。
参考URL
windows7でvagrantを使う
はじめに
現在行っているプロジェクトで最初は自分一人エンジニアで開発を行っており開発環境にVagrantを利用していたのですが、この度マークアップと連携する段階に入り、いままで自分のMacにvagrantで開発環境を作って開発してきたので、その環境をマークアップのwindowsで再現するためにwindowsでvagrantを使う方法を調査したのでまとめおきたいと思います。
vagrantとは
vagrantとは仮想環境の起動、Stop、削除をコマンドラインで簡単に操作でき、かつその仮想環境の設定(os、ネットワーク、メモリ割り当てなど)をVagrantfileという一つファイルで行なう事が出来るツールです。
このVagrantfileを共有することが簡単に仮想環境を構築できること、他の人と同じ開発環境を簡単に再現できることが魅力で使われているツールです。
vagrantについての説明はよりわかりやすい説明がされているブログがあるので、ここでの説明は省略します。
インストール手順
vagrant インストール
まず公式サイトからダウロードします。Windowsを選択して、ダウロードして下さい。
インストールしたファイルをダブルクリックして、あとは説明に従えば上手く行きます。
VirtualBoxをインストール
vagrantで利用する仮想環境を作るためにはなんらかの仮想化ツールが必要です。ここでは自分も使っているVirtualBoxを利用するのでインストールします。
公式サイトのダウロードページにある「VirtualBox 4.3.28 for Windows hosts -> x86/amd64」を選択してダウロードして下さい。
ダウンロードしたファイルをクリックしたらインストールが始まります。ここも説明どおり進めていけば問題ありません。
VirtualBoxのパスをユーザー環境変数Pathに設定する
vagrantがVirtualBoxを使用するためにユーザー環境変数PathにVirtualBoxのパスを設定する必要があります。 特別に変更せずに進めていれば、C:\Program Files\Oracle\VirtualBoxにインストールされているはずなので確認して下さい。
VirtualBoxをインストールしたパスが確認できれば、それを環境変数に設定します。
環境変数の設定するにはWindowボタン->Computer->System properties -> Change settingsとを辿ると以下の設定画面を表示させます。(画像は英語になっているので日本語に読みかえて下さい。)
画面の下にある「Environment Variables」ボタンをクリックすると環境変数設定画面に入ります。
環境変数の設定画面には上部の「ユーザー環境変数(User variables for ユーザー名)」と下部の「システム環境変数(System variables)」があります。
ユーザー環境変数のPathに先ほど確認したVirtualBoxのPathを追加したのですが、もしすでにPathがあればすでに書かれている値の後に追記してください。 もしなければNewボタンをクリックして、新規に作成します。
vagrantで仮想環境を立ち上げる
インストール&設定が上手くいったか確認するため、vagrantを使ってみる。
好きなディレクトリに移動して、以下のコマンドを実行してください。
$ vagrant init hashicorp/precise32
成功するとVagrantfileが作成されます。 そのVagrantfileで定義された仮想環境を立ち上げるには以下のコマンドを実行します。
$ vagrant up
上手くいけば指定された仮想環境のboxのインストールから立ち上げまで行ってくれます。
注意点
もしvagrant upしたときにエラーが発生し、「VirtualBoxがインストールされていない」というエラーメッセージが表示された場合まだ環境変数Pathがコマンドプロンプトに反映されていないのが原因かもしれません。 一度コマンドプロンプトを再起動させると上手くいくかもしれないので試してみて下さい。(自分はWindows自体を再起動したけど。。)
課題
vagrantで立ち上げた仮想環境にsshで簡単にログインできるコマンドでvagrant sshというのがありますが、Windowsだとデフォルトでsshクライアントが入っておらず使えない。。
生のHTMLを書くことが辛くなってきた。
自分はWebアプリケーションエンジニアで、 1年程前まではサーバーサイドをPHPで書いていたのでその延長でHTMLを書くことには特に何も思うことはありませんでした。
ただこの一年ぐらいはサーバーサイドにRubyonRailsを採用してSlimというテンプレートエンジンを使っています。 SlimというのはHTMLをもっと簡易的にかけるツールで、例えば以下のようなHTMLを
<!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <title>Sample File</title> </head> <body class="sample"> <div id="contents"> <h1>Sample File</h1> <img alt="yterajima" src="http://www.e2esound.com/images/yterajima.jpg" /> <p>テキストテキストテキスト</p> <p>テキストテキストテキスト テキストテキストテキスト</p> </div> </body> </html>
以下のように簡易記法でかけます。
doctype html html head meta charset="utf-8" title Sample File body.sample #contents h1 Sample File img src="http://www.e2esound.com/images/yterajima.jpg" alt="yterajima" p テキストテキストテキスト p | テキストテキストテキスト テキストテキストテキスト
もし興味があれば、slimの詳しい説明は公式サイトや速習テンプレートSlim(HTML作成編)を見ていただけるとよくわかるので参考にしてみてください。
一度Slimのようなテンプレートエンジンを使うと、書くコードが格段に減りますし、コードが減るので効率、可読性、メンテナンス性も格段に上がります。 その恩恵を受けると、生でHTMLが辛くなってくるんですよねーー。
フロントエンド開発にRailsアプリでもnodeのエコシステムを使うという選択
はじめに
RailsではデファルトでAsset Pipelineという機能により、SassやaltJs(CoffeeScriptやTypeScript)のコンパイルやファイルの結合、圧縮を行ってくれる機能があります。 なので通常はバックエンドをRailsで開発する場合はフロントエンドもRailsに沿って開発を行います。
最近自分がメイン開発者(というかほぼ一人?)として新Webサービス開発プロジェクトが始まり、バックエンドのフレームワークはRailsを使うことにしたのですが、様々な検討の結果フロントエンドはRailsのエコシステムではなく、nodeのエコシステムを使うことを選択しました。
振り返ったときにこの選択が正解だったのかどうかを確認するためにも、ここでなぜこの選択をおこなったのかをまとめておきたいと思います。
依存性の管理にnpmを使いたい
フロントエンド開発を生産的に行うに、当然様々なライブラリを扱います。
そのライブラリを管理するのに一番ベタな方法はライブラリのソースをダウンロードしてライブラリ用ディレクトリに設置することです。
そこから少し進化したのが、Bowerというパッケージ管理ツールのbower.jsonにアプリが依存しているライブラリを明記してインストールするようになりました。
ただ最近ではnodeが提供している標準のパッケージ管理システム npmを、そのままフロントエンドJavaScriptの依存性管理にも使えるようにするbrowserifyというツールも使用されるようになっています。 このbrowserifyが優れもので、サーバサイドのnodeでライブラリを使用するときに行うrequire('module名')をフロントエンドJavaScriptの世界でも使えるようにしてくれます。
var react = require('react')
あくまで私の観測範囲ですが、フロントエンドに関する記事やライブラリのREADMEなどを見ているとフロントエンドJavaScriptの世界での依存管理でもnpmを使うことが前提となっていく感じがしていて、それが出来ないがために何かを行うときに無駄にハマってしまう予感がしています。
他チーム、他プロジェクトへノウハウの共有がしやすい
フロントエンド開発は高度化、複雑化しており、上記にあげた依存性の管理の他にもSassやAltJSのコンパイルや圧縮、結合、ライブラリの選定や設計など様々な問題を解決しなければなりません。 これらをRailsエコシステムにのった方法で解決しても、その知識は他のフレームワークを利用したプロジェクトやチームと共有できません。
うちの会社で行われる開発でRailsを選択するのは私がメンバーに入るときぐらいで、他の場合はCakePHPやほとんどバックエンドが必要ないWebサイトの制作が大多数を占めています。
自分が学んだ知識を他のチームとお互いに共有したり、また他のチームの開発に入った時に自分がスムーズにヘルプできるようにし、会社全体でのフロントエンド開発の生産性を高めるためにもフロントエンド開発ではnodeのエコシステムに乗るべきだと判断しました。
おわりに
今回のプロジェクトではサービスの企画立案から、開発に関わる技術選択、実際の開発まですべてに関わることができるのですが、あらためて「どの技術を選択するか」を考えることの難しさと面白さを感じました。
良い技術選択を行えば、開発者のモチベーションアップや生産性アップにもつながれば、その逆に陥ることもあります。
今回意識したのは「1年後の当たり前になっているか」ということで、1年後はいま以上にフロントエンド開発のnode前提は加速すると予測し、この選択を行いました。
この選択によって、このブログにフロントエンド界隈のポストが増えてくると思います^^*
chefに疲れたあなたにはItamaeがおすすめ!
chef使うのめんどくさくないですか?
私はいままでサーバーの設定を自動化するためのツールにchefを使っていました。 最初chefを使い始めた時は、いままで手作業でやっていたことがコード化・自動化できるので「お、便利ー!chef最高!」という感じだったのですが、 だんだん使っていくうちにchefが高機能が故に自分の用途としては使うのが辛くなってきました。
そもそも自分はchef soloしか使わない
chef は基本的にはchef-server - chef-client という構成で、設定を自動で行いたいサーバーに対してchef-clientをインストールします。 そして対象のサーバーの設定をコード化したrecipeを保持するchef-serverとchef-clientが通信して対象サーバーにrecipeを適応します。
このchef-serverを立てずにchef-clientだけでサーバーの設定を自動化するchef-soloという機能があり、それは自分の手元のマシンからSSH経由でchef-clientにrecipeを送信・適応させるのですが自分の場合はそもそもこれしか使っていません。
管理しているサーバーが何十台もあって常に稼働している場合はchef-serverがあって自動でrecipeを適応させる機能も価値があるかもしれないですが、自分の場合は管理対象のサーバーがそもそも多くないからです。
覚えることが多過ぎる
一つのサーバーの設定を管理するchefのレポジトリを作るためにchefだけでなくなく、コミュニティが作ったrecipeの依存管理をするBerkshelf、chef-soloを使うためのコマンドラインツールknife-soloなど、なんだかんだで必要なツールを覚えるために結構な学習コストがかかります。
最近はchef-soloではなく、chef-zeroだと言い出している
自分はそもそもchef-soloしか使っていないのに、そのchef-soloが終わりchef-zeroを使って欲しいそうです。
詳しい内容は以下のブログを参照してください。
From Solo to Zero: Migrating to Chef Client Local Mode | Chef Blog
いまからまた新しいchef-zeroとかのプラクティスを学ぶのが辛いです。。。
もっとシンプルなツールが欲しい!
chefは大規模にサーバーを管理している人にとっては学習コストに見合うメリットがあるツールなはずだけど 、自分にとってオーバースペック過ぎました。 もっと単純に、ホストマシンでコマンド実行したら対象サーバーにrecipeを適応するだけの、シンプルなツールが欲しいと思って調査し始めました。
Itamaeはシンプルで使いやすい!
ItamaeはchefのようなDSLで、 よりシンプルな機能だけを実装したツールです。
たとえば、以下のようにhttpdをインストールするrecipeを作成します。
package 'httpd' do action :install end
このrecipeを対象サーバーに適応するには以下のコマンドを実行します。
$ itamae ssh -h 192.168.10.10 -p 22 -u user -i /path/to/private_key recipe.rb
オプションが多いですが、やっていることは明白で-h で対象サーバーのホストを指定し、-pでポートを指定、-uで接続ユーザーを指定、-i で秘密鍵を指定、最後に適応させるrecipeファイルを指定します。
chefのようにnodeによって値を変えたい場合は、以下のように-jオプションで利用するjsonファイルを指定すればいいだけです。
$ itamae ssh -j node.json -h 192.168.10.10 -p 22 -u user -i /path/to/private_key recipe.rb
ちゃんと知りたい場合はGithubレポジトリのwikiを見れば、推奨されるベストプラクティスから使い方までちゃんと記載されていますし、量も少ないのですぐに使えるレベルまで学習できます。
自分のようなchefに疲れた人にとって、itamaeはchefで学んだ知識もある程度活かせ、かつ簡単に使えるベストなツールです!
さらに嬉しいのはchefは対象サーバーにruby + chefをインストールしないといけないですが、itamaeはその必要もないのです。
もし他にもchefに疲れた人がいらっしゃれば、ぜひitamaeをオススメします。
Vagrant、chef、 Dockerって最近よく聞くけどなにが違うの?
はじめに
先日うちの会社のアルバイトに来てくれている大学生さんに 「Vagrant, chef, DockerってよくWebで記事を読むんですけど使っている文脈が似ていて、何が違っていてどう使い分けるのかよくわからないんですよね〜」という風に尋ねられました。
その時に彼にも口頭で説明はしたのですが、うまく説明出来たのか自分でも怪しかったので今回まとめてみたいと思います。
Vagrantとは
Vagrantについて、 Vagrant日本語ドキュメントには以下のように説明されています。
Vagrantは、 あなたとあなたのチームの生産性/柔軟性を最大限にする手助けをするために、 簡単な環境設定/複製可能なマシン/業界標準の技術で構築された1つの一貫したワークフローによって制御される可搬的な開発環境を提供します。
その恩恵を得る為に、Vagrantは先人の知見に基づいています。 マシン(開発環境のマシン)は、ViretualBox, VMWare, AWS, そのほかのプロバイダにより提供されます。 そして、シェルスクリプト/Chef/Puppet といった業界標準的に提供されているツール類は、 マシン上のソフトウェアを自動的にインストール/設定するために使用されます 。
ざっくりいうとVagrantとは仮想環境の設定・操作用統一ツールです。
いままで開発用の仮想環境を作成しようとすると仮想環境用ツール (VirtualBoxやVMWareなど)を使い、OSのイメージをダウンロード・インストール、初期設定などをいろいろ行って初めて仮想環境が構築できます。
しかしそれをチームメンバーそれぞれが行うことでOSのバージョンの違い、仮想環境ツールの違い、仮想環境ツールの設定の違いなどが発生してしまい、みんなが同じ環境で開発を行うことが難しく手間がかかる作業でした。
Vagrantを使う場合 、それらの仮想環境の設定がすべてVagrantfileという設定ファイルに記述され、 仮想環境の操作もvagrantというコマンドラインツール経由で行います。
仮想環境の設定がVagrantfile経由で行われるため、チームメンバーに同じ環境を構築してほしい場合はそのVagrantfileを使ってその人も同じようにvagrant経由で仮想環境を起動すると同一の環境が簡単に手に入るということです。
他にもVagrantではホストマシンとゲストマシン (Vagrantで作成した仮想環境)の指定したディレクトリを同期する機能がデフォルトで簡単に利用できるため、いままで仮想マシンで開発を行っていた ローカルでファイル編集 => 仮想環境にアップ => 仮想環境内で実行 というフローが ローカルでファイル編集=> 仮想環境で実行 という風に簡略化できます。
Vagrantはローカルマシンに構築する仮想環境の他にもAWSのEC2をvagrantコマンドでコントロールすることも可能ですが、個人的には本番環境と開発環境を同じツールで簡単に操作できるのは少し怖いところもあるので、Vagrantはあくまで開発環境の構築&操作ツールとして利用しています。
chefとは
chefについて、@ITの記事では以下のように説明されています。
「Chef」とは、システム構築を自動化するためのソフトウェアツールあるいは枠組み(フレームワーク)の一種。システムの各種設定を変更したり、アプリケーションやミドルウェア、コンポーネントなどのソフトウェアをインストールしたりする作業を自動化できる。WindowsやLinux、Mac OS Xなど複数のプラットフォームに対応している。
chefはざっくりいうとサーバー設定ツールです。
例えばPHPをつかったWebアプリケーションを動作させるためのサーバーを設定しよう思うとWebサーバーとしてApacheをインストールし、PHPをインストールし、DBを使うならMySQLなどをインストールします。もちろんサーバーの構築はこれだけでは終わらず、セキュリティ用にネットワークの設定をいれたり、ツールをインストールしたり、インストールしたツール群の設定などもそれぞれ行う必要があります。
サーバーの設定を行うのが一台だけならまだ良いのですが、冗長化するために複数台サーバーを立てる場合に すべて手作業で行うのは効率が悪いのでそれらの設定作業をプログラミングで自動化しようというのがchefの役割です。
他にもchefは冪等性(何回実行しても結果は同じ)という特徴をもっているため、すでに稼働しているサーバーに対して実行しても環境を壊すことなくchefで記述した環境に収束させます。
そのためchefのコードを見るだけでサーバーの現在の状態が把握できるドキュメントの役割も果たしてくれます。
Dockerとは
Dockerについて、またまた@ITさんの記事では以下のように説明しています。
「Docker」とは、Docker社(旧dotCloud)が開発するオープンソースのコンテナー管理ソフトウェアの1つです。
上記の説明で記載している通りDockerはコンテナー管理のツールであるため、コンテナー型仮想化技術と強く紐付いています。
仮想化にはホスト型、 ハイパーバイザー型、コンテナー型と幾つか種類があり、上記で説明したVagrantで使用しているVirtualBoxが行う仮想化はホスト型、AWSの EC2やさくらクラウドなどクラウドサービスなどで使われる仮想化はハイパーバイザー型の仮想化です。
それぞれの仮想化技術の詳細については長くなるため省略しますが、 コンテナー型と他の仮想化との違いはその軽さです。
他の仮想化技術は仮想的な「物理マシン」を作りだすというアプローチのため、物理マシンの上の仮想空間に独自のLinuxカーネルやOSなどをインストールしますが、コンテナー型では物理マシンのLinuxカーネルは共有して、別々のユーザー空間を作り出すというアプローチを取っています。
Dockerではコンテナー型で作られた仮想環境をDockerfileという設定ツールを使って設定を入れ込んでいきます。 それによってそのDockerfileを使えば同じコンテナー型の仮想環境が作成できます。
それぞれのツールの関係
vagrant & chef
vagrantとchefはとくに一緒に語れることが多いので混同されやすいのですが、vagrantは仮想環境の操作・設定ツールでchefはサーバー設定ツールです。 よく使われるパターンだとvagrantで作った仮想環境をWebアプリケーションが動作できるようにするためにchefで設定を入れる、のような感じです。
「Vagrantfileでもサーバーの設定を入れる」と思ってしまうときがあるのですが、Vagrantfileではサーバーの設定を入れるためにシェルスクリプトを使おうがchefを使おうがどちらでも構いません。 Vagrantfileで行うのは「このコマンドを使ってサーバーの設定をおこなう」という入り口を提供してくれているだけで、その設定ツールの選択肢のひとつとしてchefがあるという関係です。
vagrant & Docker
まったく関係ありません。
vagrantは仮想ハイパーバイザー型やホスト型仮想化ツールを通して仮想環境を操作するのに対して、Dockerはコンテナー型の仮想環境を操作します。
ユースケースが似ているため混同されるかもしれないですが、お互い対象としている仮想化技術が違うため組み合わせて使うことはまずないと思われます。
chef & Docker
組み合わせて使うことも可能ですが、あまりメリットがないかもしれません。
chefはサーバーを構築する際にその対象となる環境でrubyとchefが実行できればサーバー設定を行うことが可能なので、Dockerで作ったコンテナー型仮想環境でも設定の自動化のために使用することは可能です。
ただDocker自体にDockerfileというサーバーの設定を記述して自動化する機能を提供しているため、それをchefに置き換える必要があまりありません(既存のchefの資産が生かせるというメリットはありますが・・)
さらにDockerで作成するコンテナー型仮想化技術はプロセス内でその仮想環境が構築され、そのプロセスを消すと仮想環境自体もなくなるため基本的には毎回一からDockerfileを使って仮想環境を構築することになります。 chefのメリットのひとつに冪等性がありますが、それが有効なのはすでにchefによってサーバーの設定が入っているところに何度も実行しても環境が同じであることを保証したいからです。 Dockerのように毎回一から作成する環境の場合は何度も実行することがそもそもないので冪等性は不要になります。
なのでDockerを使うのであればサーバーの設定もchefを使わずDockerで完結させる方が適切でしょう。
終わりに
Vagrant, chef, Dockerがまだわからない人にざっくりとした説明ができるようにこの記事を書いてみました。
本当はDockerの使いどころなども必要なので書きたいと思ったのですが、体力が尽きたのとそんな記事はいくらでもあるのと、何よりまだ自分が仕事で使っていないという理由で書くのは省略しちゃいました ><
Web開発の現場だとほとんどVagrantとchefに類似するサーバー設定ツール(Puppet, Ansibleなど)は使うのはもうスタンダードになっていて、Dockerはまだこれからだが確実にスタンダードになる技術っていう感じだと思います。
Dockerを使う場合はアプリケーションの設計自体も変更が必要になる大きな変化なので、しっかりとキャッチアップしておきたいな。
参考URL
Vagrantを使う理由 | Vagrant日本語ドキュメント
Windows Insider用語解説:Windows/Linuxで使えるシステム構築・設定の自動化ツール「Chef」とは? - @IT