ReactJS: Keep Simple. Everything can be a component!
[2014-01-09-1] からmasutaka.netのCIを開始したが、残念ながら masutaka.netに直接serverspecする、なんちゃってCIだった。 masutaka.netにcookしてからPRを出して、WerckerにCIさせていた。 WerckerとAWSを連携させて、テストのたびにサーバをまっさらな状態から 作り、終わったら破棄することが可能になったので、ここに記録しておく。 去年くらいに話題になったこの辺の話。 Vagrant + Chef Solo + serverspec + Jenkins でサーバー構築を CI - naoyaのはてなダイアリー naoya/circleci-serverspec なんで今までやらなかったかというと、cookが一発で通らないレシピになっ ていたから。。気づいてはいたんだけど、本番サーバのテストが通りさえ すればよかった
7 月に開催された「JAWS-UG 三都物語 2014」でも発表したとおり、自分が関わっているプロダクトをオンプレミスから AWS に移行しました。 JAWS-UG 三都物語 2014 に登壇しました 移行して 2 ヶ月ほど経ちましたが、目立った障害もなく安定した運用を続けています。スライドでも少し触れていますが、これまでのやり方を大きく変えるキッカケにもなりました。 今回は「オンプレミスから AWS に移行して変えた 3 つのこと」と題して、社外に公開できる範囲でご紹介します。 稼働中のサーバに変更は加えない いわゆる Immutable Infrastructure の考え方を取り入れました。最初は流行りに乗りたかったという気持ちが大きかったのですが、今では昔のやり方にはもう戻れません。 オンプレミスでは本番稼働中のサーバにログインして何か変更するということが当たり前に行われていました
概要 TerraformのAWSを使って、CLIを通してインスタンスの起動→変更→停止を行うためのチュートリアル。Terraform の基本概念である plan apply show のサイクルを理解するためのもの。 追記 Terraformのblog投稿、参考訳 - Qiita http://qiita.com/zembutsu/items/402e02950ce9d59fa0e6 Terraform入門 日本語訳 - Qiita http://qiita.com/zembutsu/items/84f5478701c5391df537 Terraform とは Hashicorp (Vagrant, Packer, Serf, Consul を作っている会社) によって 7/28 に公開された新しいオープンソースのプロダクト。 Terraform http://www.terraform
Images as codePacker standardizes and automates the process of building system and container images. Multi-cloud image workflowCreate one workflow for images across multiple clouds and private infrastructure. Extend Packer with pluginsPlugins extend Packer’s functionality without modifying Packer's core by adding new builders, provisioners, post-processors, and data sources.
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
Chef Casual Talks Sapporo Vol.1 映像→https://www.youtube.com/watch?v=zJ7pYVp5M7E&feature=youtu.beRead less
このエントリは前後編に分かれています。前編は主に運用フローやそこでの工夫点、後編は実際の運用から得た知見や今後の課題といった内容です。 ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (前編) ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (後編) 最近はインフラ運用・DevOPS関連のトピックとして目にしないことはないくらい、「イミュータブルインフラストラクチャー」について様々な議論がなされています。私たちも昨年、継続的デリバリという文脈で、@IT の連載にてその基本的な考え方について紹介させていただきました。 さて、今年の二月にローンチをしたばかりのヌーラボのシングルサインオンサービス「ヌーラボアカウント」では、イミュータブルインフラストラクチャの一歩手前として、特定の変更を加える場合のみ、ごっそり環境ごと入れ替えるというやり方にてその運用をスタートしました。
クックパッドのデプロイとオートスケール、1日10回デプロイする大規模サイトの裏側（後編）。JAWS DAYS 2014 大規模なオンラインサービスを支えるためのオートスケールと、サービスをすばやく進化させていくための迅速なデプロイ。クックパッドはこの2つをクラウド技術の組み合わせによって両立させています。 同社のインフラ責任者である成田氏がその仕組みやルールを、Amazonクラウドのユーザーコミュニティ主催のイベントJAWS DAY 2014で解説しました。 （本記事は「クックパッドのデプロイとオートスケール（前編）。JAWS DAYS 2014」の続きです） オートスケールはAmazon Auto Scalingを使わないと判断 今日の本題であるオートスケールの話をしたいと思います。 オートスケールとは一般に、トラフィックが増えたらサーバを増やしましょうね、という作業を自動化するものです
何もかも投げ棄てて Dark Souls II をやりたい気持ち抑えながら JAWS DAYS 2014 で Immutable Infrastructure について話してきました。以下、資料です。(Embed できないのでリンクです) https://speakerdeck.com/naoya/immutable-infrastructure-number-jawsdays Immutable Infrastructure トラックのトップバッターだったので、そもそも Immutable Infrastructure とは何か、どのような背景でこのような概念が提唱されるに至ったのか、そして現在は。またこれから何が変わるのかみたいな、大枠の話にフォーカスして話しました。会場は Immutable Infrastructure トラックは立ち見が出てるくらい盛況で、やはりこの分野に注目が集
ITエンジニアが幸せになれば、社会全体が幸せになる。だから仕事だけでなくプライベートでも幸せになってほしい――。1月17日に開催されたWebエンジニア向けイベント「エンジニアサポートCROSS 2014」で注目を集めた異色のセッション「エンジニアの恋・愛・セックスのDevOps、ホントのところどうしたらいいの？」。エンジニアが幸せな恋・愛・セックスを勝ち取るにはどうすればいいのかをテーマに、男女4人の登壇者が2時間にわたって真剣で熱い議論を交わした。 「エンジニアが幸せになれないのは、社会の何かがおかしいのでは」 同セッションのセッションオーナーを務めたのは、サーバーワークスの小室文さんだ。小室さんといえば、クラウド／AWSのスペシャリストとして知られるエンジニアだ。これまで数多くの男性エンジニアと共に仕事をしてきた小室さんだが、“彼女いない歴≒年齢”のエンジニアや、結婚したくてもできない
AWS OpsWorks（Chef や Puppet を使って運用を自動化する）| AWS
重要なお知らせ AWS OpsWorks では、サポート終了が近づいており、新規のお客様を受け付けていません。詳細については、以下のサポート終了時のよくある質問をご覧ください。 AWS OpsWorks スタックのサポート終了に関するよくある質問 (リンク) AWS OpsWorks for Chef Automate のサポート終了に関するよくある質問 (リンク) AWS OpsWorks for Puppet Enterprise のサポート終了に関するよくある質問 (リンク) AWS OpsWorks は、Chef や Puppet のマネージド型インスタンスを利用できるようになる構成管理サービスです。Chef や Puppet は、コードを使用してサーバーの構成を自動化できるようにするためのオートメーションプラットフォームです。OpsWorks では、Chef や Puppet を
スタートアップ企業等の少人数チームの場合、専任のシステム運用担当がいることは稀だと思います。本記事では、そうした少人数チームの開発兼運用担当者を主な対象として、システム運用の重要な要素である「システム稼働状況の確認、障害対応」を省力化するための方法の一つとして「システムの監視」の方法について説明します。 少人数チームでのシステム運用 Retty開発担当の鹿島です。第1回で少し紹介しましたが、RettyはWebサイト、iPhoneアプリ、Androidアプリの計3プラットフォームを、3人＋αの開発者で開発を進めています。私は主にWebサイトの開発とインフラ全般を担当しているのですが、Webサイトの開発がメインのため、インフラ構築・運用に割ける時間はそれほど多くありません。 おそらく世間の小規模チームの大半では、我々と同様に専任の担当者がいないと思われます。今回の記事はそうしたスタートアップ企
Immutable （不変な） Infrastructure は、サーバを一度セットアップしたら二度と変更を加えないという運用スタイルのことを指します。 クラウド環境では、必要に応じてすぐにサーバを用意し、不要になったら簡単に破棄することができます。Immutable Infrastructure は、このようなクラウドの特性を活かす運用スタイルとして、注目されつつあります。 背景 Immutable Infrastructure が提唱された背景にある技術として、 Auto Scaling や Blue-Green Deployment*1 などがあります。 Auto Scaling Auto Scaling は、負荷に応じて自動的にサーバ台数を増減させる技術で、 AWS では標準で提供されています。常に必要な台数だけ起動していればいいので、コスト削減になるというものです。 Auto S
Amazonクラウド、デプロイの自動化ツール「AWS OpsWorks」公開。Chefのレシピ利用
クラウドのような大規模な基盤に対してアプリケーションを展開するには、自動化ツールが欠かせません。ChefやPuppetのような新しい運用自動化ツールが注目されているのはそのためです。 Amazonクラウドは、Chefを利用した運用自動化ツールの「AWS OpsWorks」を公開しました。Amazonクラウドのユーザーであれば追加料金はかからず、無料で利用可能です。 AWS OpsWorksを用いることで、大規模なクラウドアプリケーションを展開するのに必要なOSやミドルウェア、データベースサーバなどを多数のサーバにインストールし、ロードバランサーを設定し、アプリケーションをインストールするといった作業が自動化できます。大規模なアプリケーション展開でも、迅速に作業できるようになるでしょう。 OpsWorksの設定 AWS OpsWorksでは、まず管理単位となる「Stack」を定義し、どのリー
先日 Las Vegas で開催された AWS re:Invent 2013 に参加してきました。 非常に活気あふれる大規模なカンファレンスで、大変刺激を受けました。 今日は、いま何かと話題になっている Immutable Infrastructure に関連した発表を2つ紹介します。 Stop Worrying about Prodweb001 and Start Loving i-98fb9856 slideshare: Stop Worrying about Prodweb001 and Start Loving i-98fb9856 (ARC201) | AWS re:Invent 2013 AWS の Chris Munns 氏による発表です。タイトルからして面白いですね。エモいです。 この発表は以前から目をつけていたんですが、スケジュールの都合で出られず、残念でした。こうしてス
2. Copyright © 2013 AGREX INC. 2 プロフィール てるい まさし 照井 将士 http://www.facebook.com/marcy.terui (株)アグレックス 札幌事業所 システム部 1987年 東京都大田区生まれ 1992年 札幌移住 2011年 (株)アグレックス入社 担当業務 ・ECサイトを中心としたWEBシステムの受託開発、運用 役職 ・下っ端、雑用係 担当職務 ・インフラ構築、管理という名の雑用 ・アプリケーション設計、実装、テストという名の雑用 ・雑用という名の雑用 ・雑用という名の(ry 好きなサービス ・CloudWatch ・Route53 13年9月10日火曜日 3. Copyright © 2013 AGREX INC. 2 プロフィール てるい まさし 照井 将士 http://www.facebook.com/marcy.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
