50
52

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

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

Last updated at Posted at 2015-07-19

 
AmazonWebservices_Logo.png

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

前提

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

前回までの振り返り

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

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

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

クラウド

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

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

Amazon Web Services (AWS)

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

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

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

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

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

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

似た感じね・・ :pensive:

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

$ vagrant up

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

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

$ vagrant up --provider=aws

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

Heroku

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

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

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

heroku-langs.png

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

$ git push

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

なぜ Docker入門でそんな話を?

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

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

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

2013年ごろに日本でも話題になった(けど最近はあまり聞かない)
Immutable InfrastructureDisposable Components11を実現するために
Dockerへの期待が高まっていった背景です。

今回のまとめ

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

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

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

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

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

04.Dockerのよさ

 

  1. 仮想環境ではない、Windowsや Macの起動時に最初に立ち上がるOS

  2. ホストOSに対して、仮想環境として動作する OSはゲストOSと言います

  3. プラグラマブルですね。プログラマなみなさんとは相性抜群です!

  4. AWSでは、サーバのスナップショットに起動に必要な情報を加えた AMIを生成します

  5. 高性能なサーバに変えるのはスケールアップ、隣にサーバを増やすのはスケールアウト

  6. 状態とはいえ、プロセス情報やメモリの状態は保存されませんが・・

  7. ランディングページ。きっとホームページと「似た感じ」では作れません

  8. 任意時点のサーバの状態が保存してある、AWSのサーバの

  9. 最短はきっとこう。実は筆者にはここまで単純化した経験はないです・・

  10. 作ったものを利用可能な状態にすること。本番環境にデプロイ≒リリース作業

  11. http://www.publickey1.jp/blog/14/immutable_infrastructure.html

50
52
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
50
52

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?