オープンソースカンファレンス2015 .Enterprise https://www.ospn.jp/osc2015.enterprise/
Chef, Consul を使ったクラウドオーケストレーション
オープンソースカンファレンス2015 .Enterprise https://www.ospn.jp/osc2015.enterprise/
細かすぎて伝わらないかもしれない、CircleCIでDockerをごにょごにょするときのスピードアップテク - パラボラアンテナと星の日記
前回、「Dockerコンテナにcookしserverspecでテストをする」ということをやりました。 キャッシュ活用などによる高速化などが課題でした。今回はいくつかの課題を解決させ、テスト時間の短縮を図りました。 (「スピードアップテク」とか書きましたが、勝手に自分がハマってたところを改善したりしてるだけの箇所もあります。) 先に結論：対策後のビルド時間 対策前(build#9) docker imageキャッシュ有効時(build#55) docker imageキャッシュ無効時(build#54) load docker image 1m41s 0m20s 1m00s knife solo cook(nginxのインストール) 2m56s 0m12s 0m21s (other) (1m03s) (0m41s) (1m06s) TOTAL 5m40s 1m13s(!!!!!) 2m27s
最近書いたChefのCookbook(all-in-one_haproxy, redis)を公開します - 元RX-7乗りの適当な日々
公開します、というかGitHubに置いていただけですがー。 all-in-one_haproxy 2台セットでのHA構成を想定したHAProxyサーバを作るためのChef Cookbookです。2台セット冗長化済のHAProxyサーバをさくっと作るために書きました。 https://github.com/namikawa/all-in-one_haproxy 基本的には、2台で以下機能が連携しあう形で稼動します。 rsync + lsyncdの稼働 (各種設定ファイルの同期) keepalivedの稼働 (HAクラスタ構成の実現) HAProxyの稼働 (LB/ReverseProxyソフトウェア・SSL対応) iptables/ip6tablesの稼働 (接続元の限定) Quaggaの稼働 (エッジルータ等との動的経路広報の実現) snmpdの稼働 (各種メトリクスの取得) swap領域
Knife-SoloからKnife-Zeroへの移行 #getchef - クリエーションライン株式会社
はじめに 前回は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
Chefのレシピについて、attributeの優先度を実際に試して見ながら調べてみた。
報告が遅れましたが、すごい広島#9に参加してきました。 今回は、Chefを触っていて気になっていた、attributeの優先度について、実際に試して見ながら調べました。 まず、chefのグローバル変数？ともいうべきattribute変数には、１５レベルの優先度が設定されています。（参照先） 初めは、上書きできる変数がしかも１５レベルもあって、無意味じゃないかと思っていましたが、 それなりに理由はあるのです。（理由がないとそもそもそんな機能は実装されない） それは、Chefのレシピは単独で使われることはまずなく、多くは組み合わせて使われるという事です。 例えば、Apacheのレシピでは、初期値としてポート番号80を設定したとします。 Apache単独で使用する場合はほとんど問題にならないでしょう。 しかし、Tomcatと組み合わせる場合、場合によっていはポート番号がぶつかるので変更する必要が
さくらのVPS Ubuntu14.04LTS初期設定 -berkshelfのインストール- | schrödinger.jp
berkshelfをインストールします。 berkshelfはcookbookごとの依存関係を解決してくれるので、手作業で依存関係を解決する手間を省くことができます。 shelfなので、cookbookをまとめる本棚みたいなイメージなのかもしれません。 gemでインストールします。 gem install berkshelf 通常は上記でOKのはずですが、執筆時点で最新の3.1.1はgecode関連の問題でインストールに失敗してしまいました。 原因は、ビルド時に2GB近くのRAMを消費するからだそうです。 This gem runs make with concurrent jobs to speed build time, so it uses about 2GB of RAM during the build. If this doesn’t work for your envi
Chefで公開したくないJSONデータを暗号化するためにDataBagsを利用してみた記録 · さよならインターネット
May 20, 2013 ruby 1.8.7 chef 11.4.4 knife-solo_data_bag 0.3.2 2013/05/20 現在 knife-solo 0.2.0 では “knife solo data bag” は使えず https://github.com/thbishop/knife-solo_data_bag こちらを利用 参考 About Data Bags — Chef Docs Encrypt a Data Bag — Chef Docs knife-solo_data_bagのインストール # gem install knife-solo_data_bag # cd /root/chef/ ; pwd 暗号化用の鍵を用意 # openssl rand -base64 512 > encrypted_data_bag_secret 環境整備 # mkdi
アルパカchef日記３日目 data bagについて / またはユーザ管理クックブックなど - アルパカDiary Pro
２日目の続き。 コンセプトはこちらをご参照下さい。 ３日目の目標 ユーザ管理(data bag) ユーザ作成 bash_profile管理 sudo ここの段階で ec2-userのsudo権限を剥奪し、新ユーザにsudo権限を付与 security_limit ３日目を始める前に：data bag ユーザ情報など、クックブックを跨るグローバルな値を cookbookにいちいち書くのは得策ではありません。 さらに生で置いておくのも気が引けますね。 そんなご要望にお答えするために「data bag」という仕組みがあります。 databagを作成しておくと、複数のクックブックにまたがっている共通の変数などを保存しておくことができます。 シークレットキーを作成する まずはdata bagを暗号/複合するためのシークレットキーを作成しましょう。 以下のコマンドでdata bag用の鍵ファイルを作っ
Chefを読んで実行するための全知識 - Qiita
このドキュメントでは、Chefを実行して、インフラを作成したい人が、既存のレシピがあるのを前提に、Chefの概要を理解するためのドキュメントです。Chef-soloの構成のみに対応した記述になっています。理解が間違えているところとかあればご指摘ください。 1. Chefの概要 1.1. Chefとは シェフは、インフラストラクチャーをコードに変換するための自動化プラットフォームです。仮想環境でも、物理環境でも、クラウドでも使う事ができます。インフラストラクチャを自動化することで、プロダクトのマーケット投入を早めたり、スケールや複雑さに対応したり、システムを安全に保ちます。 1.2. Chefの仕組み Chefはサーバーをセットアップして、希望の状態にするための「クックブック」「ノードオブジェクト」というDSL(設定ファイルっぽいもの)をローカルのワークステーションで作成します。それらのDS
Etsy chef-workflow
Etsy uses Chef for infrastructure configuration and management. They have around 1000 nodes managed by around 30 devops engineers making regular changes. Chef Server and GitHub Enterprise are used to manage configuration code and changes. Knife-spork is used as the deployment tool to promote changes through development, staging, and production environments. Monitoring and notification tools like I
サーバ構築・デプロイの自動化の話。或いはChefとCapistranoの素敵な関係 - プログラマでありたい
最近のChefのブレイクで、サーバの構築も自動化でという潮流になっています。そんな中でチラホラ見受けられるのが、アプリのリリースもChefでという考え方です。私は微妙に違うのではないかなぁと思っているので、ちょっと考えを整理してみました。併せてCapistranoの紹介もしてみます。 Chefの役割 まずChefについてです。Chefの役割としては、サーバの状態を管理するものです。ここで言うサーバの状態というのは、各種ミドルウェアのインストール状態＆設定です。いわいるサーバ構成ですね。またChefを使う最大のメリットは、開発環境やステージング環境、本番環境と全ての環境を同じスクリプトで構築するので、手作業によるミス等による微妙な差異が発生しなくなることです。 さてここで問題になるのが、サーバ上のアプリケーションのコードやデータベースのテーブル定義は、サーバの状態に入るのかという点です。入る
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
入門Chef Solo落ち穂拾い
http://dl.dropboxusercontent.com/u/224433/pfcasual_1/index.html