タグ

awsとchefに関するriki0084のブックマーク (7)

  • はてなのサーバ管理ツールの話 - YAPC::Asia Tokyo 2013

    はてなの自社製サーバ管理ツールの思想と設計を紹介します。 はてなでは数千台のホストを運用しており、運用を効率化するためにサーバ管理ツールを自社で開発しています。 このセッションでは、「はてなにおけるサーバ運用に求められるもの」と「パフォーマンスメトリクスの可視化」の話をしたいと思います。 実装言語はもちろんPerlです。 はてなにおけるサーバ運用に求められるもの 数千台ホストの管理 デプロイツール(Capistrano)、監視ツール(Nagios)、プロヴィショニングツール(Chef)との統合 自社データセンタ環境とクラウド環境(AWS)の透過的な管理 パフォーマンスメトリクスの可視化のしくみ MySQLNginxなどの様々なミドルウェアのメトリクスを取得するためのエージェントの実装 メッセージキュー(TheSchwartz)を用いたエージェントのタスクマネージメント RRDToolを用

  • Vagrant + Jenkins の CI を AWS でも回す - naoyaのはてなダイアリー

    昨晩 Jenkins と Vagrant で CI だ、と書いたら という反応があった。確かに、可能なら物理サーバに依存しない形でテストできるとより嬉しい場面もありそうですね。 しかしそこは Vagrant。Vagrant はバージョン 1.1 から、バックエンドを VirtualBox だけでなく AWS (EC2) などの IaaS を指定して仮想サーバーを作ったり壊したりできるようになっています。詳しくは http://d.hatena.ne.jp/naoya/20130315/1363340698 この辺を。この機能を利用すれば昨日の Jenkins + Vagrant のフローをほとんど変えずに、EC2 のインスタンスでのインテグレーションテストができそうですね。 速見もこみち「では、早速やっていきましょう。」 Multi VM でローカル/リモート両対応に せっかくなので Vi

    Vagrant + Jenkins の CI を AWS でも回す - naoyaのはてなダイアリー
  • Puppet on AWS

    July Tech Festa 2015での講演資料です。 Ansibleのモジュールの仕組みや開発方法について、ちょっと掘り下げて話しています。

    Puppet on AWS
  • Amazonクラウド、デプロイの自動化ツール「AWS OpsWorks」公開。Chefのレシピ利用

    クラウドのような大規模な基盤に対してアプリケーションを展開するには、自動化ツールが欠かせません。ChefやPuppetのような新しい運用自動化ツールが注目されているのはそのためです。 Amazonクラウドは、Chefを利用した運用自動化ツールの「AWS OpsWorks」を公開しました。Amazonクラウドのユーザーであれば追加料金はかからず、無料で利用可能です。 AWS OpsWorksを用いることで、大規模なクラウドアプリケーションを展開するのに必要なOSやミドルウェア、データベースサーバなどを多数のサーバにインストールし、ロードバランサーを設定し、アプリケーションをインストールするといった作業が自動化できます。大規模なアプリケーション展開でも、迅速に作業できるようになるでしょう。 OpsWorksの設定 AWS OpsWorksでは、まず管理単位となる「Stack」を定義し、どのリー

    Amazonクラウド、デプロイの自動化ツール「AWS OpsWorks」公開。Chefのレシピ利用
  • AWS News Blog

    Announcing Amazon Managed Service for Apache Flink Renamed from Amazon Kinesis Data Analytics Today we are announcing the rename of Amazon Kinesis Data Analytics to Amazon Managed Service for Apache Flink, a fully managed and serverless service for you to build and run real-time streaming applications using Apache Flink. We continue to deliver the same experience in your Flink applications without

  • AWSブログを3行でまとめる試み#4 : 新サービス AWS OpsWorks を発表するぞ - naoyaのはてなダイアリー

    AWS OpsWorks という新サービスを始めたぞ。AWS で動かすアプリケーション全体の管理を集中 & 自動化できるぞ。細かい調整は chef でするんだ。 Stack と呼ばれる設計図みたいなのを作っておくとそこから、ボタン一発で Rails + memcached + HAproxy + MySQL みたいな好きな組み合わせで立ち上げられて、git からアプリケーションコードをデプロイして動かすなんてことができるんだ。しかも Autoscaling の設定とか障害時のインスタンス差し替えも一括でできちゃう! (ドヤァ) OpsWorks の利用には料金はかからない。また今日からもう使えるぞ。びっくりだろう? すみません。今回は内容が濃いいので「まとめる」というか勝手に解釈して3行で書いてます。 cf: http://aws.typepad.com/aws_japan/2013/02

    AWSブログを3行でまとめる試み#4 : 新サービス AWS OpsWorks を発表するぞ - naoyaのはてなダイアリー
  • 開発メモ#4 : EC2スナップショットとの差分は chef-solo で解決 - naoyaのはてなダイアリー

    開発メモその4です。 開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー で、システム構成の変更時に EC2のスナップショットからインスタンスを複製して Elastic IP で切り替えているという話をしました。 ただ、この方法はそのままでは一点問題があります。スナップショットを取ったタイミングと現時点でシステム構成に差分があった場合にどうするか、です。例えば nginx の設定をほんの少しだけ書き換えたい、とかその都度スナップショットを取っていては流石に面倒。 その手のスナップショット時点からの差分を複製されたインスタンスに簡単に適用するために、基的なサーバー設定周りは chef-solo で管理してます。chef はサーバー構築自動化ツールで、chef-solo は chef のクライアント・サーバーを必要としないライト版、とでも

    開発メモ#4 : EC2スナップショットとの差分は chef-solo で解決 - naoyaのはてなダイアリー
  • 1