テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-TIS株式会社で行った社内勉強会（西新宿Tech-Circle）の資料です。 Test-Kitchenを使ってTDDを実践する方法をご紹介しています。 資料内で出てくるGitLabやJenkinsのLT資料は以下リンクより見れます。 http://www.slideshare.net/yoshimitominaga/ss-36972336
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
AWSチーム社内勉強会「Ansible」レポート | DevelopersIO
はじめに こんにちは、虎塚です。 先週金曜日の18:30から1時間、AWSコンサルティング部でAnsibleをテーマに社内勉強会を開催しました。この記事では、会社の活動紹介を兼ねて、勉強会の様子をレポートします。 秋葉原オフィスと札幌オフィスにいた社員、東京や札幌近郊でリモート勤務中の社員10名以上が、Skype接続して実施しました。写真は、秋葉原オフィスの会議室に集まったAWSチームメンバーです。 今回の講師は植木さんでした。植木さん自身も上越からのリモート参加で、Skypeを使って画面共有しながら説明とデモを実施してくれました。上の写真で皆がディスプレイを食い入るように見ているのは、そのためです。 Ansibleの説明 デモンストレーション Ansibleをインストールする brew install ansible ssh/configを作成する ここで.ssh/configを自動生成
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の自動更
Serverspecテストコード実例の紹介とコード記述の際のポイント
第1回では、Serverspecの概要とテストコードを書くまでの事前準備についてご紹介しました。第2回では、より具体的な環境を例として、実際に即したServerspecのテストコードの書き方をご紹介します。テストコードを記述する際のポイント等をまとめ、テストコードの記述をスムーズに実施できるようになることを目的として解説します。 LAMP構成のシステムのテスト 具体的なシステムとして、LAMP（Linux、Apache HTTP server、MySQL、PHP）構成の環境を想定し、この環境に対するテストコードの一例を紹介します。 LAMPの構成を採るシステムの例として、今回は統合監視ソフトウェアのZabbixを稼働させるための環境を取り上げます。LAMP環境のベースとなるLinuxは、CentOS 6.5を想定しています。 稼働状況のテストとして、大まかに以下の4つの部分に分けて各部分の
環境構築自動化の手順と評価検証、Puppetの基礎知識
R子 今日から担当に配属されたR子と申します。よろしくお願いします。 K男 こちらこそよろしく。ところで、R子さんは今までサーバー構築の経験はあるのかな？ R子 入社時の研修でちょっとだけ……。 K男 R子さんも明日からばりばり構築してもらうよ。1日最低10台がノルマね。 R子 えぇ!? 不安だなぁ…… ちゃんと家に帰れます？ うぇ～ん。 さて、R子さんは一体どうなるのでしょうか。1日10台がノルマといわれていますが、サーバー構成が同じ場合、一度構築してしまえば似たような単純作業の繰り返しになります。この単純作業を自動化することにより、効率的にサーバーを構築できるようになります。自動化できれば、10台であろうが、100台であろうが怖くありません。 本連載では、こんなときに役立つサーバー構築の自動化技術について紹介していきます。 初心者でもサーバー構築／運用が自動化できるように サーバー構築
KAIZEN platform Inc. における運用自動化
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
Consul + Capistrano でオーケストレーションさせてみた - log.fstn
はじめに 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
「実践DevOps! SonicGarden流Herokuガチ運用術！」というテーマでCIO安達とHerokuでの運用について話しました | mah365
運用＝監視ではない。現状把握（監視）＋リスク低減（リカバリ）＝運用である。 今「データ保全に細心の注意をはらっている」と言いましたが、単純に「バックアップが行われているか？」「コピーしたDBダンプが保存されているか？」をチェックするだけでは運用とは言えません。運用＝監視ではないんですね。 監視観点を網羅することでしっかりと現状把握をするのと同時に、いざ問題が起こったときに速やかにリカバリできる必要があります。 SonicGardenでは主に以下のリスクを念頭に置き、問題が起こったときに速やかにリカバリできるようにしています。 アプリケーションデータの一部が破損するリスク ログファイルを一定期間保存（デフォルト3年分）し、ログからのリカバリを行えるようにする。 データベース内のデータの一部が消滅するリスク リージョンをまたいだ冗長化バックアップを行い、もしもの場合には別リージョンを利用したサ
Fluentdで各種ログをS3とElasticsearchにまとめる - BitArts Blog
各々のサーバの様々な場所に分散しているWebサーバやその他各種ログファイルをFluentdでまとめてAmazon S3にガシガシ保存。かつ、分析用にコピーを自前のElasticsearchにも保存します。保存したログはKibanaで手軽にビジュアライズ。 Fluentdはとてもシンプルな仕組みで理解しやすい。「ログを集積したい！」と感じたらサクッと導入できる超便利ツールです。 今回は集積用サーバを経由してElasticsearchとS3に保存する構成にします。 Elasticsearchのインストール Fluentdで集積したログは保存するだけならS3で良いのですが、手軽にビジュアライズしたいので、今回はKibanaを使えるようにElasticsearchにも保存するようにします。今回はCentOSに導入するので、公式のyumリポジトリからインストールします。 $ sudo rpm --i
chefからansibleに乗り換えた5つの理由｜TechRacho by BPS株式会社
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 >
最新インフラエンジニア技術勉強会に行ってきました #dli_infra | こえむの編集後記
昨夜、ドリコムさんで行われた「最新インフラエンジニア技術勉強会 〜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
不思議の国のAnsible – 第1話 – DSS Tech Blog
DSS技術ブログへようこそ! 突然ですが、みなさんは Ansible (アンシブル) という構成管理ツールをご存知でしょうか? これから何回かに分けて1 Ansible の紹介記事を書いていきたいと思います。 新しいツールについて学ぶとき、実際に手を動かすことは理解の助けになります。 この連載では、主に構成管理ツールや Ansible をまだ使ったことのない方たちに向けて ストーリー と チュートリアル で追体験ができるような内容をお届けすることを 目指しています。 今回はその一回目。いわゆるイントロダクションです。 不思議の国のAnsible2 第1話 インフラの落とし穴にはまって なぜ Ansible を使うのか 都内某所のWeb系企業、オフィスの片隅で REALFORCE3 の静電容量無接点方式キーボードを 小気味よく奏でて複数のターミナルを縦横に操り Linux サーバ4を管理して
Dockerイメージをchef-soloでプロビジョニングする | DevelopersIO
はじめに DockerでコンテナイメージをbuildするときにはDockerfileにOSイメージの指定や導入パッケージ、実行したいコマンドなどを記述してパッケージングします。 このDockerfileはほぼコマンドべた書きのような形なので難しいわけでは無いのですが、実行処理が多くなればなるほど長く読みづらくしまうし、テストも大変です。また既にChefやPuppet、Ansibleなどの構成管理ツールを用いているのであれば、既存の資産をうまく流用したほうが楽が出来ます。 ということで、Dockerfileにはほとんど仕事をさせずに、Dockerfileからchef-soloをキックしてコンテナをプロビジョニングしてみました。 やってみた ファイル構成は以下のような形です。今回はopscode謹製のbuild-essentialをレシピとして用意しました。 . ├── Dockerfile
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
人間を考慮した自動化
サービス改善はログデータ分析から
日本語版 : IBM Bluemix
元運用担当者が,現役時代に本当に欲しかったもの. Osc2014 kansai kyoto terraform introduction
継続的デリバリーと読み解く Web 開発あるあるとその対策
How we cook cookpad.com
