ブログからの引用です。ブログはこちら 今回はアーキテクチャパターンとかリファクタリングで有名なMartin Fowler氏のブログであげられていた "InfrastructureAsCode"(原文はこちらを勝手に解釈して意訳してみましたという内容です。 意訳 感想 さっそくいきましょう。 インフラストラクチャーアズコードというのはコンピューティングやネットワークをソフトウェアシステム同じように扱えるようにソースコードを通じて定義するアプローチである。こうしたコードは可監査性やビルドの再現可能性を実現するために管理され、テストの方法や、継続的デリバリーの実現のやり方に依存する。これはクラウドコンピューティングプラットフォームを扱う方法としてここ数十年行われてきた方法だし、これからのコンピューティングインフラストラクチャーを扱う主要な方法である。 私(Fowler氏)は、鉄器時代に育って、当
Chef、アプリケーションを実行環境ごとパッケージングする「Habitat」をオープンソースで公開。仮想マシンやベアメタル、Dockerなどのインフラに依存せず実行可能に 一般的にアプリケーションを実行するには、そのアプリケーションを実行するための実行系やライブラリ、環境変数といった、いわゆる実行環境を整えることが必要です。そして実行環境はアプリケーションの外側にあり、OSやインフラとして整備しておく必要がありました。 例えばアプリケーションをビルドし、テストし、デプロイし、運用していく場合、その環境それぞれでアプリケーションの実行環境を整備する必要があるわけです。 Habitatをひとことで説明するならば、アプリケーションを実行環境ごとパッケージすることで、インフラ側で実行環境を整備する手間を省き、どのインフラでも簡単に実行できるようにしたものと言えます。 ChefのCTOで共同創業者の
近況 3月から DevOps 関連の技術的負債の解消に取り組んでいて，動かなくなった Chef を直したり，秘伝のタレ（手動）で構築されたサーバ設定を Chef にリバースエンジニアリングしたり，Serverspec を導入して稼働中のサーバの差異を確認したりしている． 他にもウェブサーバのパフォーマンスチューニングをしたり，Zabbix / Kibana / CloudWatch で可視化したり，不要なアラートを消したりもした．あと Vagrant 環境を自動構築できるようにしたり，Packer を使って Vagrant Box を改善したり，デプロイ手順を正常化したり，テストの品質向上の目的で Capybara を導入したりもした． 最近はキャッシュサーバをリプレイスしたり，AWS のネットワーク構成を変更するなど，とにかく様々な施策を試しているけど，全然まだまだという感じで，圧倒的成
Infrastructure as Code という言葉が現れてから少なくとも8年ほど経過しており、この言葉もすっかり定着したように見えるが、Martin Fowler 氏が最近自身のブログで Infrastructure as Code について触れており 、また、氏の同僚である Kief Morris 氏が O'Reilly Media から Infrastructure as Code という本を出す（現在 Early Relase 版や Free Chapters が入手できる）ようなので、このタイミングで改めて Infrastructure as Code について、その歴史を振り返るとともに、現在の状況について整理してみようと思い、このエントリを書くことにした。 内容的には、以前書いた インフラ系技術の流れ と若干重複してる部分もある。 そういえば日本でも最近、サーバ/インフラ
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
※2016/04/24 追記 昨年末にItamae meetupで話した時のスライドリンクを追記しました。 Databag > itamae-secret の話やConsul連携の話が追加されています。 http://www.slideshare.net/tsuyoshitorii5/itamae-meetup-vol1public 現在自分が運用管理しているChef-soloプロビジョニングの仕組み 1 を Itamaeに移行した時のお話をしようと思います。 管理規模としては大規模ではなく、小〜中規模的なところかと思います。 （ロールによってレシピ切り分けたり、環境毎にレシピ用意したりなど…） 最初に: Itamaeについて https://github.com/itamae-kitchen/itamae 軽量なChef と考えればよいでしょう。 Chefの複雑さを取り除き、必要十分な部
今年の6月にChef Soloは役割を終え、今後引退への道をたどると言うアナウンスがChefの公式ブログでありました。Chef Soloがなくなるということは、必ずChef Serverが必要になると言うことでしょうか？答えはなんとYesです。 しかし安心してください。そのためにChef Zeroが用意されています。一言で言うと、Chef Zeroはローカルで動かせるChef Serverです。 そしてChef Clientをローカルモードで動かすことでローカルのChef Zeroに接続するため、別のChef Serverは必要ありません。要するにChef Soloと同じような感覚でChefを使い続けることができます。 更にKnife-Zeroを使うとChef Solo同様にセットアップ先のマシンにChef Clientを簡単に入れることができます。そこで今回はこのKnife-Zeroを使
はじめに 前回はChef-SoloとChef-Clientローカルモードを比較し、ローカルホストの収束を行いました。今回はリモートホストを管理するためのKnife-SoloとKnife-Zeroを比較してみます。 Knife-Soloでは次図のように、ローカルファイルシステム上にあるCookbookやAttributeなどのポリシーをssh+rsyncでリモートホストに転送し、sshでリモートホストにログインしてChef-Soloを実行してポリシーを参照して収束を行います。 Knife-Zeroでは次図のように、ローカルホスト上にあるポリシーやNode Objectを参照するためのChef-Zeroを起動し、sshでリモートホストにログインすると同時にTCPポートフォワーディングを設定し、ローカルホストのChef-Zeroにあるポリシーを参照して収束を行います。 大変簡単に言うと、Knif
October 24, 2014 TL;DR Ansibleを利用したからって複雑な処理がシンプルになるわけではない 1st 対象のサーバに何か設定をする必要はないので このように少量のコードでやりたいことが実現できる。 ['-']% ['-']% cat hosts ansible.example.com ['-']% ['-']% ansible -m ping -i hosts ansible.example.com ansible.example.com | success >> { "changed": false, "ping": "pong" } ['-']% ['-']% cat playbook.yml - hosts: all tasks: - name: Install dstat yum: name=dstat ['-']% ['-']% ['-']% ansibl
ブログ書きました → Chef-Soloを100倍楽しく使うためのrsoloというツールを作りました。 http://t.co/GI1DrlMx8O #chef #knifesolo — DQNEO.php (@DQNEO) September 27, 2014 @DQNEO ご存知かもしれませんが参考までにどうぞ（最近の流れだとchef-solo -> chef local mode）: http://t.co/wNvSJz3iOR — Shuhei Tanuma (@chobi_e) September 27, 2014 全俺が泣いた。 SoloからZeroへ。Chef Client Local Modeに移行しましょう 詳しくはChef公式ブログの記事に書かれています。 From Solo to Zero: Migrating to Chef Client Local Mode Ch
[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が一発で通らないレシピになっ ていたから。。気づいてはいたんだけど、本番サーバのテストが通りさえ すればよかった
OpscodeのChefとは何なのかを中級者以上向けに説明します。 普通のHow to とは方向性が違うので注意。Read less
こんにちは。@jedipunkz です。 昨晩 Chef が Chef-Container を発表しました。 http://www.getchef.com/blog/2014/07/15/release-chef-container-0-2-0-beta/ http://docs.opscode.com/containers.html まだ Beta リリースでバージョンは 0.2.0 です。(gem だと 0.1.1) Docker を代表とするコンテナ周りの技術が最近、盛んにリリースされていますし、今 後クラウドプラットフォーム上でコンテナを使ってアプリを動かすケースも増えてくる のではないでしょうか。Dockerfile を使っても Chef-Solo を使ってソフトウェアをデ プロイ出来るのだけどそれだけだとしんどいので、コンテナに特化した Chef が出てき たってことだと思いま
データセンター内のサーバ設定やアプリケーションのデプロイなどの自動化ツールとして知られるChefが、Dockerに対応した「Chef Container 0.2.0（beta）」を発表しました。 DockerはLinuxコンテナ技術の1つとして軽量な仮想環境を実現し、分散アプリケーションを迅速にデプロイするなどの用途で広く使われようとしています。Dockerには、Dockerの構成を記述するためのDockerファイルがありますが、分散環境に適した自動化された構成手法が望まれており、現在さまざまな技術が登場しつつあります。 ChefがDockerに対応することで、既存のRecipeやCookbookといった構成ファイルをDockerの環境にも適用できるようになるため、管理者はこれまでの環境をDockerによるLinuxコンテナ環境へと移行しやすくなるでしょう。 Docker内で動作するChe
#!/bin/sh # dockerをインスコする yum -y install http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm yum -y install docker-io git jq service docker start chkconfig docker on usermod -G docker vagrant # chefをインスコする curl -L https://www.opscode.com/chef/install.sh | sudo bash # knife-soloをインスコする /opt/chef/embedded/bin/gem install knife-solo -no-ri -no-rdoc # dockerコンテナにSSHするための準備 cp /va
ども、大瀧です。 6/9〜10に行われたDockerのカンファレンスイベントDockerCon 2014で、AWS OpsWorksの開発者Jonathan WeissさんによるRunning Docker on AWSというセッションが行われました。 動画 スライド [slideshare id=35673267&doc=dockeronawswithopsworks-140609193626-phpapp02] スライドを見ると、GitHubにあるDocker Cookbook(Opscode Community Cookbooksにもあります)を用いてOpsWorksのインスタンスでDockerコンテナを実行する雰囲気が紹介されているのですが、実際には一からCookbookを作ってしまっていて、アップデートが辛そうです。元のDocker Cookbookで動かそうとすると一筋縄では行
自作cookbooksは最小限にしてなるべくcommunity cookbookを使う方針で。 けっこうハマりました。特にNginx + Passengerあたりがcommunity cookbookではうまくいかず(rbenvだからいけなかったか？)、仕方なく自前でソースコードをコンパイルするレシピを書いたりした。 環境はMac 10.9 marvericksで。 お料理するよ！ Vagrant, Chef, knife-solo, Berkshelfなどのインストールは過去にやっているので参照されたし。 Vagrant Vagrantで簡単にUbuntu 12.04を動かしてみるところまで。 Chef, knife-solo CentOS 6.4でchef soloとknife soloを使ってphp実行環境を構築 berkshelfとpluginのインストール
アプリケーションエンジニアとサーバープロビジョニングツール
自分はサーバープロビジョニングといえば、AWS上の本番・ステージング・共有開発機もろもろインフラチームにまかせっきりだった。しかしアプリエンジニアがローカル開発環境を作る用途ならChefやPuppetよりもAnsibleがマッチしていると思った次第。 背景 自分の職場だと、インフラチームはPuppetのマニフェストでサーバーを管理している、例えばサーバーにインストールするパッケージ やApacheの設定である。しかし、そのPuppetマニフェストはアプリエンジニアのローカルの環境を構築する用途としてそのまま使えない。 インフラチーム管理下のサーバーにおいてPuppetマニフェストで管理されている部分はアプリケーションエンジニアは触れないため、変更を加えたい場合は都度依頼を出している。 共有開発サーバーとローカル個人環境 例えばApacheとfluentdとElasticsearchはインフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
