GoReplayを導入して、Production環境へのリクエストを複製し、Staging環境に転送する仕組みを作った - Glide Note
結構前に作っていたんですが、いろいろと忙しくてブログに書くタイミングを失していたので年末のタイミングで紹介。 TL;DR GoReplayを利用して、Production環境のリクエストを複製し、Stagins環境、開発環境に投げる仕組みを作った インフラ構成の大きな変更無しで、手軽にProduction環境の実リクエストを複製し、開発、動作検証ができるようになった 2016年の弊社サービスのDocker化や、インフラ構成の大幅な変更、ミドルウェアのアップデート、アプリの改修時のバグ事前検知と事故防止に大いに役に立った GoReplayの説明 GoReplay Goで書かれており、バイナリを設置し、オプションを指定し実行するだけで動作する アプリが稼働しているサーバで動く。(例えばNginx+Railsが稼働しているサーバで一緒にGoReplayを動かす感じ。) libpcap を利用して
AWS Application Load Balancer + Amazon ECS でDockerのホットデプロイ環境を構築した - Glide Note
TL;DR AWS Application Load Balancer(以下ALB) + Amazon ECS でDockerのホットデプロイ環境を構築した ALBのTarget GroupとECSのServiceを紐付けることで、ALB配下のコンテナの入れ替えが自動で行われるようになる ALBは先日リリースされたばかりで、私もまだ色々と検証している段階なので、内容や認識等に誤りがあるかもしれないのでご容赦下さい。(詳しい人教えてください!!) その他弊社の前提情報 GitHub + CircleCIが連携済み Docker RepoにはAmazon EC2 Container Registry(以下ECR)を利用 DeployはGitHubのデプロイブランチへのマージを契機にCircleCI経由で、Docker Pushとecs-deployでDockerデプロイを実施 準備 ALBとE
Alpine LinuxなDockerイメージにServerspecを実行する環境を作った - Glide Note
TL;DR Alpine LinuxなDockerイメージにServerspecを実行する環境をMacとCircleCI上に作った CircleCI環境では lxc-attach コマンドが必要なので、spec_helper.rb で環境差を吸収するようにした 今後よく利用しそうなので、流用しやすい形でGithubに置いておいた glidenote/docker-alpine-serverspec-sample 前提 最近Kaizen Platform, Inc.で利用している一部Docker ImageをAmazon LinuxベースのものからAlpine Linuxベースのものに置き換え中。 Alpine Linuxについては@stormcat24さんのブログが一番参考になります。 今までDockerイメージにServerspecを実行するときには、コンテナ内でsshdを立てて、ssh
「サーバ/インフラエンジニア養成読本 DevOps編」にて[CircleCIによる継続的インテグレーション入門]を執筆しました - Glide Note
サーバ/インフラエンジニア養成読本 DevOps編 [Infrastructure as Code を実践するノウハウが満載! ] (Software Design plus) 2016/02/26 に出版される「サーバ/インフラエンジニア養成読本 DevOps編」というムック本にて、特集「CircleCIによる継続的インテグレーション入門」を執筆しました。 CircleCIによる継続的インテグレーション入門 私が現在所属するKaizen Platform, Inc.でもCircleCIをヘビーユーズしており、サーバ/インフラ部分においても、 インフラCI 稼働中サーバへのプロビジョニング DNSレコードの管理 Terraformを用いたAWSリソースの管理 Packerを用いたAMI作成 稼働中サーバのセキュリティアップデート メトリクスグラフの取得&slackへの投稿 などにCircl
Roost Laptop Standで肩こりが解消した - Glide Note
Roost Laptop Stand: Portable, Lightweight, Adjustable, Ergonomic Stand Kickstarterで注文していた新しいRoost Laptop Standが昨年末に届いて、最近は下のような形で作業している。 2016年に向けた作業環境が整った A photo posted by Akira Maeda (@glidenote) on Dec 28, 2015 at 1:17am PST 1ヶ月半くらい、この状態で過ごしてみての感想は、 真っ直ぐを向く姿勢になるので、肩こりが解消した 姿勢が楽なので集中力が長時間持続する イヤホンを接続するとケーブルが邪魔 Roostは持ち運びを想定した設計だが、キーボードとかも一緒に持ち歩かないといけないので、持ち運びには適さない(と思う) 単に目の高さにディスプレイがくるようになれば良いの
ChatOps + NightmareでメトリクスグラフとBIレポートをSlackに投げるようにした - Glide Note
Nightmare TL;DR Slack + Hubot + Nightmare + CircleCI を利用してSlackにNewRelicのメトリクスグラフやBIレポートを投げるようにした Slackなどチャットツールとのintegrationが無いツールでもグラフを投稿出来るようにした 会社のKPIやサービスの状態をSlack上からhubotを利用して誰でも簡単に確認が出来るようになった 仕組み Slack上でHubotを呼び出す(hubot-cronで自動で稼働する) HubotがCircleCIのAPIを叩いて、rebuid CircleCI上でNightmareを利用し、NewRelicやBIツールのスクリーンショットを取得し、s3にアップロード SlackのIncoming webhooksを利用してグラフを投稿する NewRelicにログインしてスクリーンショットを取るス
CDNをAkamaiに切り替えた - Glide Note
2ヶ月くらい前にCDNをAkamaiに切り替えたので、知見を公開。 (追記 2015年8月18日 私個人の認識不足で用語の使い方に問題があったので一部修正しました s/SLA 100%/高可用性構成/g) TL;DR Kaizen Platform, Inc.で利用しているCDNをAkamaiに切り替えた Akamaiはスタートアップでも利用出来るコスト感 高可用性構成のAkamaiを利用することでCDNの可用性というインフラエンジニア的に頭の痛い問題が減った CDN第一世代 AWS CloudFront CDN (-2015年1月) CDNにCloudFrontを利用 サービスで利用しているインフラのほとんどがAWSで稼働しており、 その関係でCDNもCloudFrontを選択。 CDN第二世代 CloudFront + CDN77 (2015年1月-5月) AWS CloudFront
Terraform + GitHub + CircleCI + Atlasを利用してAWSの操作を自動化した - Glide Note
TL;DR Terraform + GitHub + CircleCI + Atlas を用いてAWSの操作を自動化した 各ツールの役割は下記のような感じ Terraform => インフラへの変更ツール GitHub => .tfファイルのバージョン管理 CircleCI => CI、Terraformをawsに対して実行 Atlas => インフラの状態を記録するterraform.tfstateの管理 インフラの継続的デリバリー - naoyaのはてなダイアリーにて、言及されていた範囲(Route53の変更、Chefの適用)をAWSの操作全体に拡大した 背景 今までの問題点 AWSの各種操作がブラウザからポチポチ業… 手作業なので誤操作に気づきにくい。事故りやすい インフラの実構成がバージョン管理出来ていない ちなみにRoute53に関してはroadworkerを用いてコードで管理済
監視アーキテクチャ(Sensu,Pingdom,Mackerel,StatusPage.io,PagerDuty)についてまとめてみる(2014年12月版) - Glide Note
Sensu Advent Calendarに便乗して、Kaizen Platform, Inc.の2014年12月現在の監視アーキテクチャの話をちょっとしてみようと思う。 モニタリング領域 サービスを監視している領域 Pingdom Pingdom - Website Monitoring 外部ネットワークからのサービスの死活監視。アメリカ、ヨーロッパ、アジアなどの拠点からサービスの死活監視が出来るため、特定の地域からアクセス出来ない場合なのが検知出来る。 後述するstatuspage.ioとの連携で、障害を検知すると、サービスのステータス状況が自動で変わるようになっている Sensu Sensu | The open source monitoring framework. 監視フレームワーク サーバを内部ネットワークから監視するために利用 サーバのプロセス監視、サーバ間の疎通監視、エラ
S3 Event NotificasionsをAmazon SQSで受け取る - Glide Note
最近やっている仕事で先日発表されたS3 Event Notificationsが利用出来そうな感じがしたのでちょっと調査。 S3にファイルがアップされたらAmazon SQSで通知を受け取るようにしてみた。 S3 => SNS => SQS への通知は解説しているサイトが結構あるんですが、S3 => SQS への通知設定の 情報が見当たらなかったので、動くようになるまで、いろいろと試行錯誤を繰り返した。 特にSQSのPermission設定が恐ろしく分かりにくくに2日くらいハマったので、自分用にメモしておく。 S3 Bucketの作成 S3でBucketを作成。既存Bucketを利用する場合はここはSKIP。 今回は検証用にglidenote-sqs-testという名前でBucketを作成 SQSの設定 S3のイベント通知を受け取るQueueを作成する Queue名をsqs-testをして
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の自動更
vim-quickrunでServerspecをカーソル行単位でテストして編集効率を10倍にする - Glide Note
Serverspecが超高速で書けるserverspec-snippetsを作ったの続き。 超高速でServerspecが書けるようになったので、 今度はvim-quickrunを使って、 Serverspecを書きながらカーソル行だけテストを回せるようにした。 どんな感じかまた動画を用意したので、見ていただくのが早いです。 カーソル行だけテストが実行されるので、全体のテストを実行するより高速になってます。 vim-quickrunでテストを実行すると、出力に色が付かないので下記のようなsyntaxプラグインを作成。 使い方やvim-quickrunの設定例も下記にまとまっているので、参照ください。 glidenote/rspec-result-syntax g:quickrun_configにおいてcmdopt、args、execを調整すれば いろんな環境に対応が出来ると思います。 参考
Serverspecが超高速で書けるserverspec-snippetsを作った - Glide Note
Serverspec書いてますか！ Serverspecが超高速で書けるようにsnippetsを作成しました。(本当は私がResource Typesを全く覚えられないので作成しただけなんですが) glidenote/serverspec-snippets どんな感じのものなのかは動画を見て頂くのが早いです。 インストール方法や使い方はglidenote/serverspec-snippets を参照ください。 https://github.com/Keithbsmiley/rspec.vim/blob/master/ftdetect/rspec.vim みたい感じで、 filetypeをruby.serverspecへと自動指定は出来るんですが、rspecと干渉するので、ちょっと良い案を思案中。 大変便利になった 追記 2014/06/26 should <=> should_notなど
bundle openでVimfilerやCtrlP.vimやFuzzyFinderを起動する - Glide Note
10:54:44 hsbt | この Gemfile を持って来て、bundle install && bundle open が 10:54:58 hsbt | 一番、これ何だを見るのが楽だった 10:56:28 udzura | bundler benri その中で上のようなbundlerの便利情報を話していて、そういえばrebuild.fm vol.41で 同じようなこと言ってたなーと思い出して、vim使って便利に出来ないかなーと思ってやってみたら簡単にできたのでメモ。 各種Vimプラグインのインストール方法は割愛。(neobundle.vimとかを使ってください) 単にBUNDLER_EDITORという環境変数を設定するだけのお手軽TIPS VimFilerを利用する場合
開発環境の情報共有会でDash,SourceTree,Alfredの話をした - Glide Note
社内で開発環境についての情報を共有する会を開催した。 参加者全員が発表のスタイルで、ただ聞いてるだけの人がいないようにしたら いろいろな情報を共有出来て大変参考になった。 私は1日のほとんどをターミナル上で過ごすので、ここ数年GUIアプリにはあんまり関心が 無かったんですが、最近導入して便利だったやつを共有したら好評だったのでまとめておく。 Dash Dash - Documentation Browser, Snippet Manager - Kapeli ドキュメントブラウザ、スニペット管理ツール。ドキュメントをローカルにダウンロードして 利用するので高速。今日(2014/03/29)時点で130以上のドキュメントとAPIに対応していて、 プログラミング言語に加えて、MySQL、MongoDB、Puppet、Vagrantなどのドキュメントもある。 自作ドキュメントを追加することも可能
MacからVagrantコマンド一発でSSDなVPS(DigitalOcean)上にCentOS6.5+Docker環境を構築する - Glide Note
前回のVagrantとSSDなVPS(Digital Ocean)で1時間1円の使い捨て高速サーバ環境を構築する - Glide Note - グライドノートの続き。 Vagtant+DigitalOceanだけでも十分便利なんですが、先日CentOS6.5がリリースされ、正式にDockerがサポートされたので、DigitalOcean上にCentOS 6.5+Dockerな環境を用意してみる。 といっても、2013年12月20日現在DigitalOceanではCentOS 6.5なimageが提供されていないので、選択出来るCentOS 6.4のイメージを使いながら、Vagrantを利用してコマンド一発でCentOS 6.5+Docker環境が作れるようにした。 glidenote/vagrant-docker-digitalocean これは何 Vagrantを利用して、Digital
監視ソフトをNagiosからSensuに切り替えて2ヶ月経ったのでまとめた - Glide Note
新規サービス用の監視をNagiosからsensuに切り替えて2ヶ月経ったので、 導入時の調査で社内で公開してたissueと、投入して2ヶ月間運用した記録を公開しておこうと思う。 というか以前Sensuの事を書くと公言していたのに、すっかりサボっていて 昨日@ma0eさんのブログを見て下記のやり取りを思い出して急いで書いた… @ma0e We started using it. @glidenote will report the detail soon, I think. — kentaro (@kentaro) 2013, 10月 30 @kentaro @glidenote that would be nice — Mitsutoshi Aoe/maoe (@ma0e) 2013, 10月 30 導入環境はCentOS 6.4で、利用しているsensuのバージョンは0.12.1-1にな
serf-muninを導入してmunin-nodeの監視追加、削除を自動化した - Glide Note
前回の続きでSerfを触ってる。前回のエントリを見て、@zembutsuさんが作ってくれたserf-muninが素晴らしかったので、弊社仕様に若干修正して導入した。 serf-muninでmunin-nodeの監視自動追加/削除 | Pocketstudio.jp log3 Serf-muninが自動生成、削除するファイルは/etc/munin/conf.d/配下で、 既存のmunin環境(/etc/munin/munin.confとか)を壊すことがないと思うので、すぐに試すことが出来ると思う。 導入環境は CentOS 6.4 Serf 0.2.0 munin-2.0.17 で、Serfの起動コマンドや生成されるmuninのconfの関係上、Serf 0.2.0とmunin 2.0以上は必須条件になります。 serf-muninの仕組みの説明 1. web server1がmuninサー
Serf+HAProxyで作るAutomatic Load Balancer - Glide Note
hashicorp/serf Serf Serf使ってますか！サーフ！ 諸事情というか大人の事情で急遽自前でロードバランサを用意しないといけなくて、それをissueに書いてたら、 あんちぽさんがSerf+HAProxy使ったらいいのでは、 とIRCで助言をくれて、同日のmizzyさんのブログでもSerfに言及していたので、 ちょっとSerfの概要を知るためと、Serf+HAProxyが実際ロードバランサとしてどんな感じに使えるのか検証してみた。 I told @glidenote about a combination of Serf and HAProxy this morning, and he has already implemented the arch. and done investigation… — kentaro (@kentaro) October 29, 2013
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
rubocop+syntasticでRubyのコーディングルールへの準拠チェックを自動化する - Glide Note