「Amazon Web Services パターン別構築・運用ガイド」の執筆環境 - プログラマでありたい
Amazon Web Services パターン別構築・運用ガイド 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬出版社/メーカー: SBクリエイティブ発売日: 2015/03/25メディア: 大型本この商品を含むブログ (2件) を見る 今回の「Amazon Web Services パターン別構築・運用ガイド」は、会社の同僚たち4人で書き上げました。会社の同僚といっても、東京と大阪に別れていたり、日中に打ち合わせをする時間もないので、ほぼリモートのやり取りだけで完結させました。かなりスムーズにいったのですが、幾つか課題もあるので、忘れないうちにメモです。 執筆を支えるシステムの全体像 リモートでやり取りをする為に、幾つかのツールを組み合わせて簡単な環境を作りました。方針としては、執筆に集中するために出来るだけSaaSを利用し、余計な時間を取られないようにしまし
Ruby製の構文解析ツール、Nokogiriの使い方 with Xpath - プログラマでありたい
RubyでHTMLやXMLをパースする構文解析ツールの定番は、Nokogiriです。スクレイピングする際の必需品で、なくてはならないモジュールの１つです。ただ色々なことが出来る反面、どこから取りかかれば良いのか解り難い部分もあります。自習を兼ねて、Nokogiri概要と主要な機能を紹介してみます。 Nokogiriとは何か？ ReademeによるとNokogiriとは、「HTMLとXMLとSAXとXSLTとReaderのパーサー」で、特徴としては、XPathとCSS3セレクター経由で探索する機能を持つことのようです。他にもHTMLやXMLのビルダーの機能を持っていますが、HTMLとXMLのパーサー（構文解析器）と覚えておけばよいでしょう。 Nokogiriのクラス構造 Nokogiriは、なかなか巨大なライブラリです。10以上のモジュールと70以上のクラスで構成されていて、yardでダイア
Markdown記法+Git+md2review+ReVIEWで原稿・ドキュメント管理 - プログラマでありたい
来年は、インプットあたりのアウトプットの増加を目指しています。具体的なアウトプットとしては、ブログを書くこともその1つですし、公開・非公開を問わずに効率的にドキュメントを書いていくこともあります。その中で効率的にドキュメントを書くには、バージョン管理を含めドキュメントを管理する仕組みが必須だと思います。以前、原稿を書いていた時は、Git+MS Wordで書いていました。版管理出来るという点では良いのですが、Wordということで執筆出来る端末も限定され、またフォーマット変更もしづらいので改善を考えていました。 そんな中で、IT系の物書きの人たちの間でReVIEW良いよという話を何度も聞いたので試してみようと思いました。一方で、記述のデファクトは今後はMarkDown基本になると思うのでそちらもマスターしたいと考えています。Twitterで何気なく呟いたら、@masawadaさんにmd2rev
何故、Chefなのか？ - プログラマでありたい
AWS界隈で今一番熱いテーマは何でしょうか？色々ありますが、自動化がその1つでしょう。そして、その実現手段としてChefを取り上げる人はかなり多くいると思います。何故、今この動きが出てくるのでしょうか？ AWS登場前と登場後のサーバ構築 Chefのことを考える前に、AWS登場前と登場後のサーバ構築のプロセスを考えてみます。AWS登場前のオンプレミスサーバの構築の場合、最低でも見積もり⇒発注⇒製造⇒配送⇒設置⇒設定⇒デプロイという工程があると思います。 これに対して、AWSのアカウントが既にあれば、起動⇒設定⇒デプロイという3ステップでシステムが利用出来る状態になります。 AWSの意義 前述のことを考えるとAWSには、2つの意義があると言えます。まずクラウドという文脈で、コンピュータリソースを所有から利用へと変化させたことです。次に、コンピュータリソースを物理の制約から解き放ち、必要な時に必
サーバ構築・デプロイの自動化の話。或いはChefとCapistranoの素敵な関係 - プログラマでありたい
最近のChefのブレイクで、サーバの構築も自動化でという潮流になっています。そんな中でチラホラ見受けられるのが、アプリのリリースもChefでという考え方です。私は微妙に違うのではないかなぁと思っているので、ちょっと考えを整理してみました。併せてCapistranoの紹介もしてみます。 Chefの役割 まずChefについてです。Chefの役割としては、サーバの状態を管理するものです。ここで言うサーバの状態というのは、各種ミドルウェアのインストール状態＆設定です。いわいるサーバ構成ですね。またChefを使う最大のメリットは、開発環境やステージング環境、本番環境と全ての環境を同じスクリプトで構築するので、手作業によるミス等による微妙な差異が発生しなくなることです。 さてここで問題になるのが、サーバ上のアプリケーションのコードやデータベースのテーブル定義は、サーバの状態に入るのかという点です。入る
Knife SoloとAmazon EC2で始めるChef Solo - プログラマでありたい
Chef Soloの入門として、Knife SoloとAmazon EC2を使ってのセットアップの練習です。Chefの取っ付きにくさは、最初に色々なファイルやフォルダを用意する必要があるところだと思います。そこをKnife Soloは、コマンド1つで初期設定してくれます。ということで、Knife Soloで使い方を覚えるというのは良い選択肢だと思います。今回は、次のようにクライアントからKnife Solo経由でChef Soloを流しこんで、サーバの設定を行う構成になっています。 Amazon Linux AMIの起動 EC2のウィザードから、Amazon Linux AMIを起動します。今回利用したバージョンは、Amazon Linux AMI 2013.03です。インスタンスサイズは何でも良いので、試すだけであればMicroインスタンスで充分です。セキュリティグループなど適時設定して
Selenium2.0 WebDriverで複数ブラウザのUIテスト もう一度、Selenium再入門 - プログラマでありたい
ブラウザを使った自動テストツールの代表格であるSelenium。Firefoxのプラグインというイメージが強かったのですが、今では複数のブラウザを動かせるようになっています。更にサーバサイドからの起動も出来るので、ユニットテストの一部として組み込むことが出来ます。またSelenium 2.0系が出て、WebDriverというモノも出てきました。複数のプロジェクトがあって新旧の情報が入り交じっていますので、一度整理した上で使い方を学ぼうと思います。 Seleniumのプロジェクト Selenium IDE 恐らく多くの人がSeleniumと聞いて思い浮かべるのがSelenium IDEだと思います。Firefoxのプラグインとして、テストケースの開発を行う為のツールです。画面の操作を記録したり、それをテストケースという形で保存したりする機能を持っています。また、テストの再現も行います。 Se
初めてのVagrant - プログラマでありたい
@naoya_itoさんの入門Chef Soloとともに、にわかに注目されだしたVagrantです。Vagrantの読み方は、ベイグラントらしいです。意味は、直訳すると浮浪者ですが、意味するとことは形容詞の「あちこちに動く」でしょうね。 元々は、Oracleの仮想化ソフトであるVirtualBoxを操作する為のツールです。それが何故Chefと関係あるのという話ですが、VagrantのPluginのSaharaがもつsandboxという超絶機能のお陰です。何とこれ、サーバの状態をcommit & rollback出来るのです。いわゆるRDBにおけるトランザクション機能です。Chefのレシピを書いたことがある人は解ると思いますが、レシピを書く作業は割と試行錯誤の連続です。元に戻せるように仮想イメージ化するとか、対象の部分を丸ごとコピーしておくとか方法はありますが、割と面倒くさいです。Sandb
運用視点でChef ServerかChef Solo + Knife Soloのどちらが良いか考えてみた - プログラマでありたい
ChefとFabric、どちらが良いか悩んでいるうちに、Chefが一気にブレイクしてしまった今日この頃です。と言うことで、Chefを中心に今後のサーバ構築・運用について考え中です。そこでまず出てくる問題が、Chef Server+ClientとChef Solo + Knife Solo、どちらの構成が運用しやすいかという点です。 状況を整理する為に、まずは簡単にChef Server, Chef Solo, Knife Soloの関係や役割をまとめて見ます。 Chef Server サーバーの状態を管理し、それに関する情報を保持しておくのがChef Serverです。Client側は個々のサーバにインストールされて、Chef Serverに司令を問い合わせて実行します。Chef ServerはDBやキューなどを持ち、少し複雑な構造です。同じカテゴリーの製品として、PuppetやFabri
今更聞けないCapistranoでリリースの自動化 - プログラマでありたい
ここ数年で開発の現場でAgile開発の文化や手法が、ずいぶんと取り入れられるようになってきているようです。アジャイル開発はその根底に文化が大事ですが、それを支えるツールというのも重要になってきます。ソース管理やビルド管理、テストの自動化と色々ありますが、今回はリリースの自動化のお話です。その中で主にRails使われることが多いCapistranoの設定と使い方です。 環境の説明 ・Ruby 1.9 ・Rails 3.2 ・Passenger ・Git ・SQLite3 目指す構成 今回は単純化する為に、1サーバの中にGitのリポジトリもApache+PassengerもDBも入れておきます。また複数の環境（開発、ステージング、本番）にデプロイ出来るように、それぞれの構成を別けて記述するようにします。（capistrano-extを使用） 設定 必要モジュールのインストール $gem ins
Capistranoのタスク一覧 - プログラマでありたい
Capistranoのタスクが、具体的にどのように動くか調べてみました。最初は下記のドキュメントを参考にしていたのですが、結局ソースを見たほうが10倍簡単に理解できました。コード中のrecipes/deploy.rb辺りを一度読むことを強くお勧めします。 Capistrano recipes: deploy capistrano/lib/capistrano/recipes/deploy.rb at master · capistrano/capistrano ほとんどのタスクが基本コマンドの組み合わせ実行です。この原則を知っているだけで、deployの挙動の大部分が解るようになります。 Tasks一覧 ・deploy update + restart ・deploy:check 依存性のチェック。Gem等のモジュールだけでなく、ファイルやパス等も依存性としてチェック出来る。またdepen
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
