テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-TIS株式会社で行った社内勉強会（西新宿Tech-Circle）の資料です。 Test-Kitchenを使ってTDDを実践する方法をご紹介しています。 資料内で出てくるGitLabやJenkinsのLT資料は以下リンクより見れます。 http://www.slideshare.net/yoshimitominaga/ss-36972336
VPSならConoHa｜登録者数85万アカウント突破 - 期間限定キャンペーン実施中
まとめトクは長期利用割引サービスです。契約期間が長いほど割引率がアップし、よりおトクにConoHa VPSをご利用いただけます。
コードによるインフラ構成管理はなぜ必要？ 今さら聞けない「Infrastructure as Code」
はじめに 本連載では、インフラの構成をコードで管理するための便利なツールを使って、インフラを構築するための手順をご紹介します。今回は、Vagrantというツールを使って、ローカルマシンに仮想環境でWebアプリケーションの開発環境を作って、開発チーム内で統一した開発環境を構築する方法について説明します。 対象読者 本記事は、次の方を対象にしています。 コードを使ってインフラの構成管理をしたい人 ネットワークやLinuxの基礎知識がある人 Webシステムの開発環境を構築したことがある人 なぜ、コードでインフラの構成管理をするの？ 業務アプリケーション開発者のみなさんは、前任者が作った既存システムにバグがあり、それを修正することき、「設計書の内容と、ソースコードの中身が違う！？！」というシーンに出くわすことはありませんか？ Excelの設計書とソースコードを交互ににらめっこしながら、関係者に仕様
Knife-ZeroをマスターしてChef Soloの引退に備えよう！ | さくらのナレッジ
今年の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を使
第1回 アプリの運用監視サービスとは？ New Relic vs. Application Insights
第1回 アプリの運用監視サービスとは？ New Relic vs. Application Insights：連載：アプリケーションの運用監視（1/6 ページ） 正式にリリースしたWebサイトが正常に稼働しているかを常時監視するなら、SaaS型の監視サービスが便利だ。お勧めの2大サービスの機能概要を解説する。 連載目次 アプリケーション（以下、アプリ）を作って、テストも問題ないことを確認して、リリースする。しかし、それで終わりではない。サイトが正常に稼働しているか、性能に問題はないか、意図していない例外が発生していないかという情報を継続的に監視する必要がある。 以前は組織内に専用のサーバーを構築する必要があったが、現在はSaaSサービスで提供されているものもある。本連載では代表的な監視サービスについて解説を行う。 アプリの運用監視を行う アプリはリリースして終了ではない。最近DevOpsと
Chefを読んで実行するための全知識 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? このドキュメントでは、Chefを実行して、インフラを作成したい人が、既存のレシピがあるのを前提に、Chefの概要を理解するためのドキュメントです。Chef-soloの構成のみに対応した記述になっています。理解が間違えているところとかあればご指摘ください。 Chefの概要 1.1. Chefとは シェフは、インフラストラクチャーをコードに変換するための自動化プラットフォームです。仮想環境でも、物理環境でも、クラウドでも使う事ができます。インフラストラクチャを自動化することで、プロダクトのマーケット投入を早めたり、スケールや複雑さに対応した
新しいクラウドパフォーマンス管理サービス Mackerel 正式リリースのお知らせ - Mackerel ブログ #mackerelio
本日、Mackerelを正式リリースしました。 Mackerelは、Immutable Infrastructureを取り入れたアーキテクチャや、ChatOpsといった運用スタイルに最適化した、新しいクラウドパフォーマンス管理サービスです。 Mackerelは2014年5月8日にベータ公開し、それから4ヶ月間、機能追加と安定化を目指してきました。今後も引き続き、クラウド上のサーバとそれらによって構築されるWebサービスを管理するための、より使いやすく、より便利なサービスとして開発運用を加速させていきます。並行して国際化対応し、グローバルへの展開も積極的に行います。 本日より、フル機能をご利用いただける「Standardプラン30日間無料！」キャンペーンを実施しております。ぜひお試しください。 ご意見ご要望などがありましたら、お気軽にサポートまでお知らせください。 Mackerelの特徴 M
ChatOpsでOSのセキュリティアップデートを自動化出来るようにした - Glide Note
先日@naoya_itoさんが自身のブログ(インフラの継続的デリバリー)でKAIZEN platform Inc.のインフラについて書いていたやつの続編的な内容。 TL;DR Chat(Slack) + Hubot + CircleCI + GitHub を用いてセキュリティアップデートを自動化した GitHubのPull Requestを契機にセキュリティアップデートを実行できるようにした CircleCIが大変便利。インフラ系の作業を自動化するのに非常に合っている気がする 背景 KAIZEN platform Inc.では、 ネットワーク脆弱性スキャン アプリケーション脆弱性スキャン セキュリティアップデートの定期実行 の3つをセキュリティ系タスクとして継続的にやっていこうという話になり、今回は私が担当した、「セキュリティアップデートの定期実行」の話。 RHEL系OSにはyumの自動更
オンプレミスから AWS に移行して変えた 3 つのこと
7 月に開催された「JAWS-UG 三都物語 2014」でも発表したとおり、自分が関わっているプロダクトをオンプレミスから AWS に移行しました。 JAWS-UG 三都物語 2014 に登壇しました 移行して 2 ヶ月ほど経ちましたが、目立った障害もなく安定した運用を続けています。スライドでも少し触れていますが、これまでのやり方を大きく変えるキッカケにもなりました。 今回は「オンプレミスから AWS に移行して変えた 3 つのこと」と題して、社外に公開できる範囲でご紹介します。 稼働中のサーバに変更は加えない いわゆる Immutable Infrastructure の考え方を取り入れました。最初は流行りに乗りたかったという気持ちが大きかったのですが、今では昔のやり方にはもう戻れません。 オンプレミスでは本番稼働中のサーバにログインして何か変更するということが当たり前に行われていました
インフラの継続的デリバリー - naoyaのはてなダイアリー
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
fluentdで集約したerror_logをslackに流すと捗る - UNIX的なアレ
nanapiでは社内のチャットツールに、Slackを導入しています。Slackの便利なところはintegration周りで、要するに他のツールとの連携が非常にし易いんですね。そういった、Chatを中心にした業務効率化を最近ではChatOpsと呼んだりします。 http://nanapi.co.jp/blog/2014/07/24/nanapi_chatops/ ChatOpsの重要な点はコンテキストを共有できる点ですよね。「○○ってエラーログが出てるよ」みたいな情報を直接誰かに伝えるのではなく、ログが出ているという状態をChatを経由して同じものを見ることで、説明が非常にラクになります。 ほかにもデプロイをHubot経由で指示したり、ステータス取得をしたりなど様々な使い方がありますがやはり重要なのは同じ画面を皆が見ているということですね。そういった点がChatOpsの大きなメリットとしてあ
マニュアルオペレーションするとき気を付けたいこといくつか - ふり返る暇なんて無いね
少し思うところがあったのでメモ。 ほぼ自己流なので、もっと良いのがあれば教えて欲しいところ。 そもそもマニュアルオペレーション(手作業)するな ごもっとも。でもやらないといけない深淵な事情があるんです。 事前条件と事後条件を明確にしておく どういう状態からどういう状態に変わるべきか事前に明確にしておくべきです。 それなしに普通は作業しません。 切り戻し手順を考えておく 途中でミスる可能性があるポイントを明確にしておくこと。 それぞれのタイミングでの切り戻し手順をしっかり考えておくこと 作業手順を事前に書く オペレーション中にアドホックに手順考えないですよね? 複数手順あるならスクリプト化する できる限りステップを減らします。可能ならスクリプトを一発叩くだけにします。 set -eu は付けた方がいい eオプションはコマンドのステータスコードが0以外(異常終了)したときに、その時点で終了して
Serverspecの概要からインストールまで | 自動化時代のインフラ環境稼動テスト「Serverspec」入門 | Think IT（シンクイット）
【特別講演】なぜ東京ではなく、東海なのか？ 1500万人の製造都市から始まる「日本再興」のシナリオ 3月20日 6:30
環境構築自動化の手順と評価検証、Puppetの基礎知識
R子 今日から担当に配属されたR子と申します。よろしくお願いします。 K男 こちらこそよろしく。ところで、R子さんは今までサーバー構築の経験はあるのかな？ R子 入社時の研修でちょっとだけ……。 K男 R子さんも明日からばりばり構築してもらうよ。1日最低10台がノルマね。 R子 えぇ!? 不安だなぁ…… ちゃんと家に帰れます？ うぇ～ん。 さて、R子さんは一体どうなるのでしょうか。1日10台がノルマといわれていますが、サーバー構成が同じ場合、一度構築してしまえば似たような単純作業の繰り返しになります。この単純作業を自動化することにより、効率的にサーバーを構築できるようになります。自動化できれば、10台であろうが、100台であろうが怖くありません。 本連載では、こんなときに役立つサーバー構築の自動化技術について紹介していきます。 初心者でもサーバー構築／運用が自動化できるように サーバー構築
KAIZEN platform Inc. における運用自動化
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
“使用”より“構築”で学ぶオープンPaaS「OpenShift」
“使用”より“構築”で学ぶオープンPaaS「OpenShift」：DevOps時代のJavaプログラマのためのオープンクラウド入門（1）（1/5 ページ） オープンなクラウドで重要性を増すJava。DevOps時代のJavaプログラマはアプリケーション開発者（Dev）もデプロイや運用（Ops）面におけるクラウド／インフラ技術への幅広い理解が必要となる。本連載では、さまざまなオープンクラウド技術を紹介していく。初回は、オープンソースのPaaSであるOpenShiftを紹介。どんな技術を使ってPaaSが実装されているのかを理解しよう オープンなクラウドで重要性を増すJava 最近、これからは「DevOps時代」だといわれるようになっていますが、DevOps時代のJavaプログラマにとってクラウドサービスを使った開発は、どのようにアプローチしていくのが良いのでしょうか。 Javaは、これまでオン
ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (前編) | 株式会社ヌーラボ(Nulab inc.)
このエントリは前後編に分かれています。前編は主に運用フローやそこでの工夫点、後編は実際の運用から得た知見や今後の課題といった内容です。 ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (前編) ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (後編) 最近はインフラ運用・DevOPS関連のトピックとして目にしないことはないくらい、「イミュータブルインフラストラクチャー」について様々な議論がなされています。私たちも昨年、継続的デリバリという文脈で、@IT の連載にてその基本的な考え方について紹介させていただきました。 さて、今年の二月にローンチをしたばかりのヌーラボのシングルサインオンサービス「ヌーラボアカウント」では、イミュータブルインフラストラクチャの一歩手前として、特定の変更を加える場合のみ、ごっそり環境ごと入れ替えるというやり方にてその運用をスタートしました。
まとめてたくさん処理したい！ を解決する「Capistrano」
まとめてたくさん処理したい！ を解決する「Capistrano」：特集 DevOps時代の必須知識 インフラ運用の自動化を実現し、DevOpsを支援するツールはいくつかあります。ここではその中から「Capistrano」というツールについて、サンプルを用意しつつ紹介します。 はじめに インフラ運用の自動化を実現するツールには「Chef」や「Puppet」などいろいろあります。今回の記事ではそういったツールのうち、Capistranoというツールを簡単なサンプルを用意しつつ紹介します。 Capistranoとは Capistranoとは簡単にいうと、オープンソースで提供されている、複数のサーバ上で同時にスクリプトを実行するためのソフトウェアツールです。主に、同じ役割のサーバが複数台存在するような環境での自動化であったり、アプリケーションのデプロイ自動化に利用されています。 特にRuby On
インフラストラクチャ自動化フレームワーク「Chef」の基本
DevOpsというキーワードに関連して、「Chef」というツールの名前を聞いたことのある人も多いのではないでしょうか。この記事では、インフラにおける構成管理、展開作業を自動化するChefの構造および基本的な使い方について解説します。 インフラストラクチャ自動化フレームワーク「Chef」 Chefは、物理、仮想、クラウドといったさまざまな大きさのインフラに対して、サーバやアプリケーションの展開を容易にするための自動化フレームワークです。 Chefの重要な要素の1つに「Infrastructure as Code」という概念があります。インフラをどのように構築し、維持するべきかという定義はRubyの文法で記述され、ソースコードのように扱うことができます。つまり、あたかもRubyでプログラミングをするように、インフラの構成管理をコードによって行えることがChefの利点の1つです。 自然言語による
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス改善はログデータ分析から
