この記事は
誰もが最初はスタックしがちな環境構築。
慣れてくると何故スタックしにくくなるのかを考えると、取り組んだときに誰も教えてくれなかったあるものに関する知識が浮かび上がります。
そう、それこそはUNIX。
この記事の対象
・web開発している
・アプリは作っている
・SSHでデプロイ環境にログインできている
・けど、何をしたらデプロイが完了するのかよくわからない人
UNIX = ファイルとディレクトリと環境変数
今からデプロイしようとしている環境のOSは十中八九UNIXです。
UNIXにはディレクトリがあります。"/"がルートディレクトリで、そこから/usrとか/etcとか色々なディレクトリがぶら下がり、更に/usr/binとか/etc/httpdといったディレクトリがぶら下がっています。
ディレクトリにはファイルを置く事ができます。/usr/binの中にはcpとかlsとかmkdirのようなファイルが置いてあります。/usr/binに置かれたファイルはコマンド実行できます。
どうしてコマンド実行できるのかというと、PATHという環境変数が/usr/binを巡回経路に指定しているからです。
環境変数は他にもUSER（現在のログインユーザー）とか色々あります。
これがUNIXのほとんどすべてです。
Webアプリケーションを動かすモノ
以下の5つがWebアプリケーションを動かすために必要なもので、すべてファイルです。
ファイルですからディレクトリ中を探すと必ずどこかにあります。
- ミドルウェア：インタープリタ
- ミドルウェア：サーバー
- ミドルウェア：その他
- ダイナミックライブラリ
- インタープリタの拡張ライブラリ
環境構築とはすなわちこれら5つについて
・インストールすること
・バージョンをチェックすること
・稼働状態を管理すること
です。
構築した環境でシステムが動かないのは、これら5つのどれかに該当するものが
インストールされていなかったり、バージョンの不一致を起こしている状態です。
ミドルウェア：インタープリタ
インタープリタとは、平たく言うとソースコードを実行するソフトウェアです。
phpファイルを動かすにはphp、rubyファイルにはrubyというインタープリタが必要です。
ミドルウェア：サーバー
インタープリタとphpファイルがあっても、ブラウザはphpを実行する事ができません。（他の言語も同じです。）
ブラウザに変わってファイルを実行し、処理結果を返すのがサーバーの役割です。
ミドルウェア：その他
仮想マシンの時刻調節、外部通信など機能の根幹を支えるたくさんのミドルウェアが存在します。
ダイナミックライブラリ
単体では動かないのですが、他の複数のミドルウェアで利用される重要なプログラムです。
拡張子に.soと付いている奴らで、インストールしたけど存在がわかりにくい事が多いです。
インタープリタの拡張ライブラリ
コードを書くときに、自作関数以外の関数が使えるのは拡張ライブラリのおかげです。
最初から使える関数でも、実は別のファイルを呼び出していることもあります。
インストール
インストールとは
コンピュータにソフトウェアを追加し、使用可能にすること。
Wikipedia
いや、まあそうなんですけど。
それはつまりどういうことなのかというと？？？
インストールは、主に4つの要素から成り立っています。
・ダウンロードする
・置き場所を決める
・環境変数を作る
・ファイルを生成する
どのインストールも大体やっていることはこれらの組みあわせです。
インストールの失敗は、これらのどこかでミスが起きているということです。
ダウンロード
ミドルウェアやソフトウェアを構成するファイルはもともと環境の外にあります。
windowsなんかではインストーラーをダウンロードするのが一般的ですが、この時のダウンロードとは別に、インストールの最中に本当の構成ファイルを「リポジトリ」と呼ぶ場所からダウンロードします。
置き場所を決める
ダウンロードしたファイルは決められた位置関係に配置されて初めて機能します。
その整理を行うのもインストール中の作業です。
環境変数を作る
例えばPATHという環境変数はOSの巡回路です。巡回路にあるファイルはコマンド実行できます。
巡回路/usr/bin に"ls"というファイルがあると、lsコマンドが機能します。
PATH変数にディレクトリを追加して巡回路を増やすのを「パスを通す」と言いますが、
他にもソフトウェア独自の環境変数など、これらを作るのもインストールの中に入ります。
ファイルを自動生成する
一部のアプリケーションではインストール中にファイルを生成するものがあります。
大抵、GCC呼ばれるC言語のコンパイラをインストールしてmakeコマンドで実行します。
パッケージ管理ソフト
インストールの操作がたった4種類しかないとしても、全て手動で行うのはかなり大変。それを自動化し、決まったパターンで実行してくれるのがパッケージ管理ソフトです。
決まったパターンで実行されるのは非常にありがたいことで、このおかげでソフトウェア間の関係性もうまく保たれています。また、ミドルウェアが別のミドルウェアやダイナミックライブラリを必要とするようなケースでは、両方一気にインストールしてくれる機能も持っています。
yum, apt-get, brew
これらのコマンドはOSに付いているメインのパッケージ管理ソフトウェアです。
centOS、Amazon linuxならyum、ubuntuならapt-get、Mac OSならbrew(Home brew)。
どのパッケージ管理ソフトでも以下のような機能が必ずあります。
・リポジトリの追加
・利用可能なミドルウェアの確認
・インストール
・アンインストール
・自身のバージョンアップ
どれも動きはほぼ一緒で、手順がapt-getで書かれていたからyumではダメということはありません。
composer, gem, pip, npm
インタープリタはOSの提供するパッケージ管理とは別途、独自にパッケージ管理を行っています。
基本的な動き方はOSのパッケージ管理ソフトと同じです。
ですが、phpのcomposerは実行したディレクトリごとにライブラリをインストールするとか、rubyのgemはbundlerとセットで使うとGemfileが使えるとか、個性があるので自身の使用言語のパッケージ管理ソフトをよく調べておくことをお勧めします。
ちなみにpipはpython、npmはnode.js。あとperlの人はcpan。
サービス登録
サーバーは動かさないと機能しない
インタープリタなんかはインストールさえすればOKですが、サーバーは機能しません。
サーバーは本体をコマンドから実行する（例えば、ruby on railsのrails serverコマンド）とサーバーが動き出してページが表示されますよね。
普通に動かしても落ちてしまう
ですが、この方法で立ち上げたサーバーは画面を閉じてしまうと一緒に落ちてしまいます。
これはコマンドを入力した「シェル」の上でサーバープロセスが動いているためで、シェルが落とされるとその上で動いていたプロセスもすべて落ちてしまうためです。
systemctl
UNIXにはsystemctl(古いOSではservice)というコマンドがあり、次のような機能が付いています。
・プログラムを登録する (enable)
・プログラムを起動する (start)
・プログラムを停止する (stop)
・プログラムを再起動する (restart)
・プログラムの状態を表示する (status)
といった機能があります。
systemctlでプログラムを実行すると通常のシェルとは異なる場所で実行され、
ターミナルを閉じても終了されなくなります。
.service
systemctlにはソフトウェアではなく、実行を管理するためのスクリプトを登録します。
/etc/systemd以下に保存された.service拡張子を持ったファイルです。
大抵の場合、サービス登録が必要なソフトウェアではインストール後
本体とは別にこのようなファイルも作られています。
systemctlが効かない場合は.serviceがないか、壊れているということになります。
編集後記
普通の環境構築解説ではUNIXの仕組みをあまり説明しないと思います。
理由は直接の問題解決にならないから不評なのもありそうですが、とにかく情報の取捨選択が大変でした。（この記事も１回投稿した後、長すぎたので1/4くらいに圧縮して書き直しました。）
各論は何も書いていないのですが、流れがわかっていると安心するじゃないですか。ということで、構築中に不安に陥ったら「どこまではできているのか？」と考えるのに使ってください。