プログラマのためのDocker超入門 03.クラウド

　
![AmazonWebservices_Logo.png](https://qiita-image-store.s3.amazonaws.com/0/66457/a5fb2b89-9597-1c01-a65e-a35d30641d36.png)

今回もDockerの話まで至りません・・次回こそは・・

## 前提

`インフラ？なにか学んでいいことあるの？`なプログラマ向けの記事です。

## 前回までの振り返り

前々回の[仮想化](/pottava/items/7086f9d63487aa3d7d08)では、ひとつのホストOS[^1]の上に
`開発プロジェクトごとに隔離された`開発用の仮想環境[^2]を作ることで
`プロジェクト乱立による混乱が抑えられる`ことをお伝えしました。

前回の[構成管理](/pottava/items/5b386a952bf1d26ea387)では、専用のツールを使い
ソフトウェアのインストールや設定を`機械化・自動化`することで
`プロジェクトが依存するソフトウェアの可視化`、`作業の履歴管理`、
`人為的ミスの抑制`ができることをお伝えしました。

これだけでも`開発`は今までより始めやすく、安定したものになりますが
ここまで来ると、アプリの`リリース作業`も楽にしたい！となるわけで・・
今回の話題は、クラウドです。

## クラウド

2006年、クラウドコンピューティング事業を [AWS](http://aws.amazon.com/jp/about-aws/)が始めました。
そして2007年には、[Heroku](https://ja.wikipedia.org/wiki/Heroku)が創業しています。

それぞれが
`優れた概念`を`実際に動く機能として`提供し始めました。
以下、何がすごかったのかを見てみましょう。

## Amazon Web Services (AWS)

クラウドを売り出した AWS、そのよさとは何だったのでしょうか。

* サーバを使いたいと思ってから数分で、さまざまなOSのサーバが利用可能に
* ブラウザはもちろん、APIやSDKを通じて様々な資源を制御できる[^3]
* サーバからスナップショット[^4]を作成、そこからの新規サーバ作成も数分！
* テストや一時的なスケールアウト[^5]がしやすい課金体系

構成管理にはたくさんのメリットがありましたが
AWSにはそれと似て非なるメリットがあるようです。
つまり

* サーバそのものを構成管理のようにプログラムで管理できる
* サーバそのものの状態[^6]を保存できる
* 保存したものをベースに他のサーバを起動できる（サーバを複製できる）

## つまりこんなことができる AWS

「会社のホームページ作ってよ :wink: 」と言われ
構成管理下の仮想環境で開発し、リリースまで終えたあなた。
その旨を報告すると、こう返されます。
「お、いいね！じゃ、似た感じでいいから新サービスのLP[^7]も作って :stuck_out_tongue_closed_eyes: ！」

似た感じね・・ :pensive: 

でも大丈夫、開発環境はVagrantフォルダ以下をコピって
今回のプロジェクト用に構成管理の定義ファイルをちょっと書き変えて・・

```bash
$ vagrant up
```

これで独立した開発環境はできた。コードを書いて・・
よし、あとはこの完成したソースコードを本番環境にアップするだけ・・
となったら

ホームページを公開する際に取得した、
構成管理ツールなど自社の初期設定が済んだAMI[^8]と必要な秘密鍵を指定して

```bash
$ vagrant up --provider=aws
```

はい、本番環境へのリリース完了！[^9]
クラウドを使えばデプロイ[^10]も自動化できそうですね。

## Heroku

Salesforce.comの好きな分類に従えば当時の AWSは [IaaS](https://ja.wikipedia.org/wiki/Infrastructure_as_a_Service)、
そして彼らが買収した Herokuは [PaaS](https://ja.wikipedia.org/wiki/Platform_as_a_Service)ですが、
PaaSというだけあって、Herokuの仕組みは画期的でした。

まず自分で「環境構築」する必要がありません。
そして「デプロイ」が超絶にかんたん。

昔レンタルサーバといえば「Apache2.4系」などを選び
指定したフォルダにFTPで index.htmlをあげれば動いていましたが、
Herokuはそれをずっと高度で、しかしわかりやすいものに昇華しました。


![heroku-langs.png](https://qiita-image-store.s3.amazonaws.com/0/66457/5fbe1493-0571-8bba-ff43-5519dc028532.png)

このいずれかのプログラミング言語でソースコードを書き、
あとは

```bash
$ git push
```

とするだけ。これで本番環境が最新の状態に変わります。
インフラ層を意識する必要さえなくなりました。

## なぜ Docker入門でそんな話を？

Herokuの圧倒的な簡単さに驚いた優秀なインフラエンジニアさんたちが
ここをひとつの目標にし始めたからです。git pushで完結する世界。

1. git pushするたびに
2. 隣に新しい環境を作り
3. プロビジョニングやデプロイが完了したら
4. ユーザからのリクエストを新環境に向ける
5. 問題があれば切り替えない、うまくいけば旧環境を破棄

これはその後 Dockerの成長に繋がる話ではなく、`Dockerがあれば`
これを手軽に、時間的金銭的に低コストで実現できそうではないか・・

2013年ごろに日本でも話題になった（けど最近はあまり聞かない）
`Immutable Infrastructure`や`Disposable Components`[^11]を実現するために
Dockerへの期待が高まっていった背景です。

## 今回のまとめ

クラウドを使えば、本番環境へのリリースまで含めて
プログラムを書く業務以外はすべて自動化できそうですよね？

しかし懸念点はあります。[ベンダーロックイン](http://www.keyman.or.jp/it-word/61005149/)です。

AWSで作ったものを DigitalOceanでも動かして冗長構成をとりたい
Heroku用に作ってきたプロジェクトを GCPにも横展開したいといったとき
AMIや Procfileは他のクラウドでは動きません・・

これまで見てきた仮想化や構成管理ででてきた課題、
ベンダーロックインやまだ git pushで完結しない世界、
それらの解決を期待されているのが Dockerです。

いよいよ次回、Dockerに登場してもらいましょう！

[04.Dockerのよさ](/pottava/items/50b90403b895742467dc)へ

　
[^1]: 仮想環境ではない、Windowsや Macの起動時に最初に立ち上がるOS
[^2]: ホストOSに対して、仮想環境として動作する OSはゲストOSと言います
[^3]: [プラグラマブル](http://yougo.ascii.jp/caltar/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%83%96%E3%83%AB)ですね。プログラマなみなさんとは相性抜群です！
[^4]: AWSでは、サーバの[スナップショット](http://e-words.jp/w/%E3%82%B9%E3%83%8A%E3%83%83%E3%83%97%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88.html)に起動に必要な情報を加えた [AMI](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/AMIs.html)を生成します
[^5]: 高性能なサーバに変えるのはスケールアップ、隣にサーバを増やすのはスケールアウト
[^6]: 状態とはいえ、プロセス情報やメモリの状態は保存されませんが・・
[^7]: ランディングページ。きっとホームページと「似た感じ」では作れません
[^8]: 任意時点のサーバの状態が保存してある、AWSのサーバの
[^9]: 最短はきっとこう。実は筆者にはここまで単純化した経験はないです・・
[^10]: 作ったものを利用可能な状態にすること。`本番環境にデプロイ`≒リリース作業
[^11]: http://www.publickey1.jp/blog/14/immutable_infrastructure.html