タグ

ChefとPuppetに関するraimon49のブックマーク (10)

  • Infrastructure as Code 再考 - Gosuke Miyashita

    Infrastructure as Code という言葉が現れてから少なくとも8年ほど経過しており、この言葉もすっかり定着したように見えるが、Martin Fowler 氏が最近自身のブログで Infrastructure as Code について触れており 、また、氏の同僚である Kief Morris 氏が O'Reilly Media から Infrastructure as Code というを出す(現在 Early Relase 版や Free Chapters が入手できる)ようなので、このタイミングで改めて Infrastructure as Code について、その歴史を振り返るとともに、現在の状況について整理してみようと思い、このエントリを書くことにした。 内容的には、以前書いた インフラ系技術の流れ と若干重複してる部分もある。 そういえば日でも最近、サーバ/インフラ

    raimon49
    raimon49 2016/04/22
    ソフトウェアシステムのプラクティスを適用できるInfrastructureの拡大。2008-2009年が大きな契機だったのかな。
  • Jenkins User Conference 東京 2015

    Jenkins は長らく継続的デリバリのためのツールとして使われてきましたが、Jenkins Pipeline によって全く新しい様々な可能性が開けました。この発表では、Jenkins Pipeline からスタートして、おもちゃでない実用に耐えうる継続的デリバリのパイプラインを構築します。Jenkins のもうひとつの新機能の目玉は、Jenkins の新しい UX である Blue Ocean です。この発表では、継続的デリバリのパイプラインを構築した後、Blue Ocean を使って開発者に迅速なフィードバックをもたらす様子を紹介します。 受講対象: 継続的インテグレーションや Jenkins にご興味をお持ちの方はぜひご参加ください。 製品/テクノロジ: DevOps/OSS 川口 耕介 CloudBees, Inc. Chief Technology Officer

    Jenkins User Conference 東京 2015
  • [速報]Microsoft Azureの仮想マシン、標準でPuppet、Chefに対応。Build 2014

    米マイクロソフトはサンフランシスコで開発者向けイベント「Build 2014」を開催中。2日目の基調講演では、同社のクラウドサービスMicrosoft Azureの仮想マシンが標準でPuppetとChefに対応したことが発表されました。 PuppetやChefはデプロイやプロビジョニングを自動化するソフトウェアです。これにより多数の仮想マシンの管理が容易になります。下記はPuppetマスターによって、SQLサーバ、アプリケーションサーバ、Webサーバといった複雑な構成のデプロイ自動化が可能になることを示しています。

    [速報]Microsoft Azureの仮想マシン、標準でPuppet、Chefに対応。Build 2014
  • Developers Summit 2014 で「サーバプロビジョニングのこれまでとこれから」という発表を行いました - Gosuke Miyashita

    内容自体は基的に、第5弾 週末ランサーズ にお邪魔した時に お話した資料 と同じなんですが、この時よりも時間が少し長かったので、多少内容を追加しているのと、当時自分の中でうまく整理できてなかったけど、今は多少クリアになった部分もあって、そういった内容を盛り込んだりしてみました。 Togetter まとめ NAMIKAWA さんによるまとめ 一点お詫びしたいのは、登壇者に質問ができる Ask the Speaker というコーナーがあって、セッションが終わった後はそちらに移動、という段取りだったのですが、裏でやっていた OSS コミッタ大集合 の方でも登壇するために終了後すぐに E 会場に向かったため、Ask the Speaker コーナーに行けませんでした。もし質問するためにいらしてくださった方がいましたら、当に申し訳ないです。 今回デブサミに登壇させて頂いた経緯については、会場で

    raimon49
    raimon49 2014/02/14
    Orchestration 複数のサーバで自律協調
  • ssig33.com - Docker をプロダクトのデプロイに使う

    コミケの列に並んでたあたりのころから Docker 格的に使ってます。このサイトもさっき Docker でデプロイするような感じにしました。 Docker の利点と欠点で 開発環境の配布が容易にできる プロダクトのデプロイにつかうにはなにかとキツい みたいな意見をわりと頻繁にみかけるのですが、逆じゃねえかと思ってます。これ開発環境の配布に使うの無理でしょ。各コンテナ使い捨て前提なんだし。 Docker をデプロイに使う際の問題点としては以下があります Dockerfile に 42 個しか命令かけないみたいなやつ なんだかんだでコンテナのビルドに時間がかかる コンテナの管理とかどうするのか リバースプロキシの設定とかどうするのか 一個目に関しては頑張ってください。僕はセットアップ用やデプロイ用のシェルスクリプトを ADD して RUN させるようにしてます。シェルスクリプトセットアップ

  • 自分のプロダクトを海外でも認知してもらうには - Gosuke Miyashita

    ブログを書くまでが YAPC、ってことなので書きます。 YAPC 懇親会で @hirose31 さんと「日人の作ったプロダクトでとても優れていて日では知名度抜群なのに、海外では全然知られてない、みたいの割とあるけど、どうやったら serverspec みたいに海外でも認知されるようになるんですかね」みたいな話をしました。 serverspec の海外での知名度、といっても、日での知名度と比較すればまだまだ全然、という感じですが、たまに海外の方の tweet を見かけたり、Serverspec the New Best Way to Learn and Audit Your Infrastructure というブログエントリを書いてくださった方がいたり、Food Fight という Podcast で取り上げられたり、O'Reilly の Test-Driven Infrastruct

  • 今さら聞けない Immutable Infrastructure - 昼メシ物語

    Immutable (不変な) Infrastructure は、サーバを一度セットアップしたら二度と変更を加えないという運用スタイルのことを指します。 クラウド環境では、必要に応じてすぐにサーバを用意し、不要になったら簡単に破棄することができます。Immutable Infrastructure は、このようなクラウドの特性を活かす運用スタイルとして、注目されつつあります。 背景 Immutable Infrastructure が提唱された背景にある技術として、 Auto Scaling や Blue-Green Deployment*1 などがあります。 Auto Scaling Auto Scaling は、負荷に応じて自動的にサーバ台数を増減させる技術で、 AWS では標準で提供されています。常に必要な台数だけ起動していればいいので、コスト削減になるというものです。 Auto S

    今さら聞けない Immutable Infrastructure - 昼メシ物語
    raimon49
    raimon49 2013/11/27
    プロビジョニングツールがオーバースペックになる、確かに。
  • インフラ系技術の流れ - Gosuke Miyashita

    ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。(英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。) プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による

    raimon49
    raimon49 2013/10/29
    プロビジョニングをフェーズ毎に分けて整理。とても分かり易い。
  • 構成管理ツール Ansible について - aptheia.info

    Ansible というサーバーの設定を管理するツールの説明。いわゆる構成管理 (CM: Configuration Management) にカテゴライズされるもので、Puppet や Chef の親戚みたいなものと考えてもらえればだいたいあってる。 概要 リード開発者は Michael DeHaan で、現職の AnsibleWorks の前は Redhat で Cobbler や Func に携わっていたり、Puppet labs でプロダクトマネージャーしたりしているという経歴の持ち主。 Ansible は Python で書かれている。同じジャンルで Python 製というと Salt が有名。Chef の場合、レシピを書くためには Ruby の知識が必要となってくるけど、Ansible はどんな言語でもモジュールが書けるようになっているので、運用にあたって Python の知識は

    raimon49
    raimon49 2013/08/25
    ChefやPuppetのようなプル型ではなくプッシュ型 シンプルだし依存がPython 2.6+だけというのも良い
  • さようならPuppet、こんにちはChef - Masatomo Nakano Blog

    ここ最近、サーバの設定ファイルの管理で Chef を使い始めている。まだ全然詳しくないけど、今感じている「Chefの楽しさ」を誰かに伝えておきたかったので、ファーストインプレッションを簡単に。 Puppetを今までそこそこ使っていたので、どうしてもそことの比較な感じになっちゃいます。Puppetも良いのだけど、Chefは後発ということでさらに良くなっている感じ。 基的な仕組 これは、Puppetとほぼ同じ。クライアント-サーバ型のシステム。設定を書き、それをサーバに置いておく。クライアントはサーバと接続し、自分自身の設定を書き換えたり、必要なソフトウェアをインストールしたりする。 rubyな設定ファイル Puppetは基的に独自DSLで設定ファイルを記述すので「覚えるのがめんどくさい」「細かいこと、ちょっと無茶なことをしようとすると大変」。Chefの設定ファイルはrubyそのものなので

  • 1