AWS OpsWorksって何？ から、運用しやすくなる下準備のポイントまで：AWS OpsWorksアプリケーション運用の勘所（1）（1/5 ページ） はじめに 2013年2月にリリースされたAWS OpsWorks。筆者が試しにいじっているうちに、どう使うと便利なのか、気を付けないと逆に運用が大変になるポイントなどが見えて来ました。 本連載では、何回かに分けてAWS OpsWorksの便利な点、不便な点をおさらいしながら使い勝手を紹介して行きたいと思います。題材として、「EC-CUBE」というAWS OpsWorksに最適化されていないオープンソースのパッケージを使ってみました。 AWS OpsWorksは、Amazon Web Servicesが提供するChefをベースにしたサービスです。Chefのレシピを使ってシステムの構成などを一元的に設定できます。また、アプリケーションのデプロ
AWS OpsWorks という新サービスを始めたぞ。AWS で動かすアプリケーション全体の管理を集中 & 自動化できるぞ。細かい調整は chef でするんだ。 Stack と呼ばれる設計図みたいなのを作っておくとそこから、ボタン一発で Rails + memcached + HAproxy + MySQL みたいな好きな組み合わせで立ち上げられて、git からアプリケーションコードをデプロイして動かすなんてことができるんだ。しかも Autoscaling の設定とか障害時のインスタンス差し替えも一括でできちゃう! (ドヤァ) OpsWorks の利用には料金はかからない。また今日からもう使えるぞ。びっくりだろう? すみません。今回は内容が濃いいので「まとめる」というか勝手に解釈して3行で書いてます。 cf: http://aws.typepad.com/aws_japan/2013/02
開発メモその5です。表題どおり EC2 インスタンスの Amazon Linux で knife-solo を使う話。 開発メモ#4 : EC2スナップショットとの差分は chef-solo で解決 - naoyaのはてなダイアリー で、chef-solo を使って EC2 の環境管理をしていると書きました。うち chef-solo の実行は capistrano like な perl のデプロイツール Cinnamon に任せている、という旨を述べました。 が、件のデプロイツール任せだと chef-solo 実行の度にレポジトリ経由でレシピをサーバー側に転送する必要がある。自分は github を使っているので github に push してサーバー側で fetchc される。デプロイツールがこの辺をやってくれるとは言え、レシピの動作確認のためにちゃんと動くことが保証されていないレシ
開発メモ#1 : Cinnamon によるデプロイ - naoyaのはてなダイアリー に引き続き、その2です。 最近は個人で作るような小規模なものでも AWS を利用してホストしています。たとえ個人で作ったものとはいえ、利用するユーザーがいる以上はおいそれと落とすこともできない。かといって運用にあまり手間をかけたくない。その辺り、AWS で解決できる点が多い。 AWS の良いところはインフラが動的なので「後からどうとでもなる」ところ。 インスタンスの性能が足りないのであればスケールアップするでもいいし、冗長性が欲しくなったらそのタイミングで ELB (ロードバランサ) を用意すれば良い。その時、仮想化されていないハードウェアを使っていると移行のためにサーバーを再セットアップしたりアプリケーションをデプロイし直したりと手間がかかるところ、AWS ではその辺りの手間がほとんどかからない･･･と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
