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

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

前提

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

前々回の仮想化では、ひとつのホストOS¹の上に
開発プロジェクトごとに隔離された開発用の仮想環境²を作ることで
プロジェクト乱立による混乱が抑えられることをお伝えしました。

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

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

2006年、クラウドコンピューティング事業を AWSが始めました。
そして2007年には、Herokuが創業しています。

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

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

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

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

似た感じね・・

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

$ vagrant up

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

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

$ vagrant up --provider=aws

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

Salesforce.comの好きな分類に従えば当時の AWSは IaaS、
そして彼らが買収した Herokuは PaaSですが、
PaaSというだけあって、Herokuの仕組みは画期的でした。

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

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

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

$ git push

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

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

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

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

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

しかし懸念点はあります。ベンダーロックインです。

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

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

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