TIS株式会社で行った社内勉強会(西新宿Tech-Circle)の資料です。 Test-Kitchenを使ってTDDを実践する方法をご紹介しています。 資料内で出てくるGitLabやJenkinsのLT資料は以下リンクより見れます。 http://www.slideshare.net/yoshimitominaga/ss-36972336
![テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-](https://cdn-ak-scissors.b.st-hatena.com/image/square/07718415eed3860f94e56b02b58e1479aa01c99c/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fchefserverspec-140715194524-phpapp01-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
はじめに こんにちは、虎塚です。 先週金曜日の18:30から1時間、AWSコンサルティング部でAnsibleをテーマに社内勉強会を開催しました。この記事では、会社の活動紹介を兼ねて、勉強会の様子をレポートします。 秋葉原オフィスと札幌オフィスにいた社員、東京や札幌近郊でリモート勤務中の社員10名以上が、Skype接続して実施しました。写真は、秋葉原オフィスの会議室に集まったAWSチームメンバーです。 今回の講師は植木さんでした。植木さん自身も上越からのリモート参加で、Skypeを使って画面共有しながら説明とデモを実施してくれました。上の写真で皆がディスプレイを食い入るように見ているのは、そのためです。 Ansibleの説明 デモンストレーション Ansibleをインストールする brew install ansible ssh/configを作成する ここで.ssh/configを自動生成
はじめに Serfに続いてHashiCorpからConsulが発表されて、2ヶ月少々経ちました。 公式では Serf: service discovery and orchestration Consul: service discovery and configuration と言っていますが(http://www.serfdom.io/intro/vs-consul.html)、Consulも使い方によってはオーケストレーションできるかなと思って、試してみました。 ちなみに Serf や Consul の最近の動向については @zembutsu さんの記事がわかりやすいです ご注文は監視自動化ですか? SerfとConsulの記事まとめ そもそもオーケストレーションとは webサーバをproxyから追加したり抜いたり webサーバにデプロイしたり 障害が発生したサーバを撤去したり db
R子 今日から担当に配属されたR子と申します。よろしくお願いします。 K男 こちらこそよろしく。ところで、R子さんは今までサーバー構築の経験はあるのかな? R子 入社時の研修でちょっとだけ……。 K男 R子さんも明日からばりばり構築してもらうよ。1日最低10台がノルマね。 R子 えぇ!? 不安だなぁ…… ちゃんと家に帰れます? うぇ~ん。 さて、R子さんは一体どうなるのでしょうか。1日10台がノルマといわれていますが、サーバー構成が同じ場合、一度構築してしまえば似たような単純作業の繰り返しになります。この単純作業を自動化することにより、効率的にサーバーを構築できるようになります。自動化できれば、10台であろうが、100台であろうが怖くありません。 本連載では、こんなときに役立つサーバー構築の自動化技術について紹介していきます。 初心者でもサーバー構築/運用が自動化できるように サーバー構築
1年くらいchefを使ってサーバ構築をしていたのですが、最近ansibleに乗り換えたので紹介記事を書いてみます 1. サーバ側に何もインストールする必要がない chefは管理対象ノードにchef-clientをインストールする必要がありますが、ansibleはPython 2.4が入っていて、sshでログインできればOKです。 chefもパッケージや,knife bootstrapコマンド等があるので始めやすいですが、何もする必要がないansibleの方が敷居が低いのかなと思ってます。 例えばsshでログインできれば、以下のコマンドを打てば10.0.10.1~10.0.10.3サーバの情報をとってくれます(カーネルバージョン,CPU,メモリ,ディスクサイズ,ディストリビューション等)。 この機能はchefで使われているohai相当のことをしてくれます。 echo 10.0.10.1 >
昨夜、ドリコムさんで行われた「最新インフラエンジニア技術勉強会 〜Fluentd, Elasticsearch,Chefの実践実例〜」に足を運んできました。 タイトルにもありますように、Chef, モニタリング, Fluentd, そして elasticsearch が使われている現場の情報を伺える機会となりました。 それでは、いつものようにノートをアップしておきます。 概要 2014-05-23 ドリコム 本社 (目黒アルコタワー) 19:30-20:00 ひらしー ドリコムのInfrastructure as Code 20:00-20:30 mickey Winning the metrics battle 20:30-21:00 外山 寛 Fluentd プラグイン開発講座 21:00-21:30 yoshi_ken MySQLと組み合わせて始める全文検索エンジン「elastics
仮想化やクラウド化が進み、インフラ環境をプログラマブルに構築できるようになってきました。この流れにより、サーバ構築をプログラムにより自動化することも多くなってきています。自動化が進むと、本当に意図した通りに正しくサーバのインストールや設定が実施されているかの確認テストも自動化することが求められるようになってきています。 本記事では、このような場面で有用なサーバ状態のテスト自動化フレームワークであるserverspecを紹介します。 serverspecとはなにか? 既に多くの技術系記事にて、serverspecの紹介がされているためご存知の方も多いかと思いますが、本技術ブログでは初登場のテーマであるためserverspecとはなにか?から順を追って解説します。 serverspecは宮下剛輔氏によって開発されたサーバの状態をテストするためのフレームワークです (Serverspec公式
ども、大瀧です。 Dockerコンテナをデプロイするツールが欲しいという理由でAWS OpsWorksとの組み合わせを以前のエントリーで紹介しましたが、今回は別のアプローチでデプロイを行うGearDを試してみました。 GearDとは GearDは、Red Hat社が開発するDockerコンテナを管理するCLIツール兼エージェントです。 最近、ITニュースサイトのPublickeyで紹介された、Project Atomicのコンポーネントの1つです。Project Atomic自体はRHELベースの軽量Linuxディストリビューション(Atomic Host)を前提とするものですが、GearDは独立した造りになっており、Fedora 20およびRHEL 7-Beta(EPEL経由なのでサポートなし)で動作します。 ブログ記事 : GearD: The Intersection of PaaS
Serfが面白いと俺の中で話題にwwwwww 【改訂版】 『ニンゲンヤメマスカ→運用自動化への希望、オーケストレーション』 Masahito Zembutsu Mar 1, 2013 オープンクラウドにゃんぱすー Open Source Conference 2014 Tokyo/Spring #osc14tk 3/4追記:blogに追記しました。 LVSとSerfでDSRロードバランサを自動管理してみた話 | Pocketstudio.jp log3 http://pocketstudio.jp/log3/2014/03/04/orchestration_with_serf_to_manage_lvs/
Linux/OSS関連のエンジニアです。OSS監視ツールZabbixの日本支社、Zabbix Japanの代表も務めています。 Zabbixは重い!というツイートや情報があったりするのですが、海外ユーザーのサポート経験からZabbixのパフォーマンスは驚くほど良くなっていると思っていて、どこに違いがあるのか不思議に思っていたりします。 Zabbix社で大規模システムというと、監視対象が数千台規模以上、1秒あたりの監視項目数(Zabbixのダッシュボードやレポートメニューから見れる値、以降nvpsと書きます)が1000を超えるくらいからです。本社ではこのnvpsの値が1万に到達しようとしているユーザーをサポートしています。 海外のZabbixサポートユーザーはボトルネックになっている点についてZabbix本体に修正要望を出し、Zabbix本体のパフォーマンスを上げつつ監視規模を拡大していって
DevOps実践に有用なZabbixの機能~自動化機能で運用負荷削減:クラウド&DevOps時代の運用をZabbixで(3)(1/2 ページ) ますますクラウド化が進む環境において、システムにはより迅速な対応が求められるようになっています。変化の早いシステムを適切に運用していくためにはどうすればいいのでしょうか? この記事では、クラウドやDevOpsを前提としたITシステムの「運用」に求められることを整理し、そういった運用に対して、オープンソースの統合監視ツール「Zabbix」がどのように有効活用できるかを紹介します。 前回の記事「DevOps実践に有用なZabbixの機能~開発と運用を近づける監視」では、DevOpsを実践するに当たって、開発者と運用者をZabbixを通じてより近づける方法について紹介しました。第3回目の本記事では、運用面にフォーカスを絞り、Zabbixの自動化機能を活用
Chef使おうとしてるけどChefいろいろつらい. 具体的には以下がつらい. 独自概念多い chefのクライアントを対象ホストに入れなければならない knifeとか覚えないといけない外部ツールがある 最初からディレクトリ構成がわいわい (rails newしたときのあのきもち) 公式ドキュメントの量が多いかつわかりにくい 以前にmiyagawaさんのpodcast を聞いてたらnaoyaさんがAnsibleっていうシンプルなプロヴィショニングツールがあるっていう話をされていたので,使ってみた. AnsibleWorks | Radically simple IT orchestration Ansible 触ってて感じるイメージは,ChefがRailsでAnsibleがSinatraな感じ. ディレクトリ構成がない (一応大規模運用を考えたディレクトリ構成のベストプラクティス Best P
DevOpsというキーワードに関連して、「Chef」というツールの名前を聞いたことのある人も多いのではないでしょうか。この記事では、インフラにおける構成管理、展開作業を自動化するChefの構造および基本的な使い方について解説します。 インフラストラクチャ自動化フレームワーク「Chef」 Chefは、物理、仮想、クラウドといったさまざまな大きさのインフラに対して、サーバやアプリケーションの展開を容易にするための自動化フレームワークです。 Chefの重要な要素の1つに「Infrastructure as Code」という概念があります。インフラをどのように構築し、維持するべきかという定義はRubyの文法で記述され、ソースコードのように扱うことができます。つまり、あたかもRubyでプログラミングをするように、インフラの構成管理をコードによって行えることがChefの利点の1つです。 自然言語による
要件は 作業のログは永遠に残す必要がある いつ、誰が、どういった理由でインフラを変更したかわかるようにする ひとつ、落とすと インフラをコードで書けるようにする 開発、本番共にVMWareで構成された基盤なのでVMWareの仮想マシンが作れるコードを書く インフラコードをバージョン管理し、変更毎に構築できるかテストする コードで構築されたインフラでアプリケーションの全てのテストが通るか確認する(インフラの要件は設定ファイルがあるかどうかではなく、アプリケーションが動作するかどうか) テストは既に動作しているCIがあるので、それを使い回す ログの保持もJenkinsにしてもらおう やること Jenkinsから仮想マシン作成、OSのインストール Jenkinsのノードに作成された仮想マシンを追加 追加されたノードでOSインストール後の設定やミドルウェアのインストール 環境の整ったノードに対して
開発環境として Gitlab、Jenkins、Redmine をセットで使っているのですが、それぞれにパスワードの設定が必要となって管理が面倒です。 アカウントを一つに統合したい。ということでやってみました。 環境 Redmine 2.3.0 Jenkins 1.499 Gitlab 5.2 方針 Redmine にプラグインで OAuth プロバイダの機能を追加し、Redmine のアカウントで Jenkins と Gitlab へログインできるようにします。 Redmine に OAuth プロバイダの機能をつける やりたいことに近いプラグインがあったのですが、Rails3 以降の Redmine に対応していなかったので、fork して、ついでに日本語化しておきました。 https://github.com/suer/redmine_oauth_provider http://red
最近あっちゃこっちゃでDevOpsという単語を聞きますが、概念的な言葉でスコープが広いので簡単に整理しておくことにします。 これで5分くらいで分かった気になるかもしれません。 2009年にFlickrの人が発表した概念 http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr 概念なので、実装は個々の現場によって異なる。アジャイル開発とアジャイル開発方法論の関係のようなもの。 従来型の考え方による利害対立 Devは多くの機能を早く届けなければならない すばやい変化 Opsは安定した運用を行いトラブルを起こさないようにしなければならない 変化を避けたい それじゃビジネスに勝てない DevOpsとはDevとOpsが協力しながら、ビジネスのために継続的に成果を出す、もしくは変化に
このところ海外のIT系の記事で「DevOps」という言葉を見る機会が増えてきました。スペルからすると、開発=Developmentと、運用=Operationを組み合わせた言葉らしい、という程度の認識でしたが、どうやらアジャイル開発やソフトウェアの品質にかかわる新たなムーブメントとして認識しなければならないかも、と感じはじめています。 そこで「DevOps」とは何か? について調べてみました。 DevOpsとは開発と運用が協力し、ビジネスリスクを軽減する まずはWikipediaの「DevOps」の項目から冒頭の部分を読んでみましょう(2011年3月8日現在の記述)。 DevOps is a set of processes, methods and systems for communication, collaboration and integration between depar
入門Chef Solo - Infrastructure as Codeを読みました。アプリエンジニアだけでなく、インフラエンジニアでもあり1,000台規模のサーバを運用管理してきた経験のある元はてなの伊藤直也さんの著書です。そんなこともあり本書では一貫して実際の運用時の課題を元にChefでどう解決出来るかという観点があり、非常に実用的でした。また入門と銘打う通り、初めてChefを触る人に理解出来るように、概要説明からChef独特の用語説明とその役割、必要とされる背景まで解説してあります。またポイントとしては、Chef Server/Clientではなく、Chef Soloの入門ということです。Chef Server/Clientはフルスタックの機能を使えるのですが、その分構成がややこしくて挫折する人も多いと思います。その点Chef Soloは構成も単純で、手軽に始められるという点で非常に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く