いつまで経っても終わらないから帰れない… 途中で終了してしまうと困るので、ログアウトしても終了しないように。 作業の流れ Ctrl+Zでコマンドの中断 bgでバックグラウンドに回す jobsでジョブの確認 disownでログアウトしても実行されるようにする 実際のコマンドだと
いつまで経っても終わらないから帰れない… 途中で終了してしまうと困るので、ログアウトしても終了しないように。 作業の流れ Ctrl+Zでコマンドの中断 bgでバックグラウンドに回す jobsでジョブの確認 disownでログアウトしても実行されるようにする 実際のコマンドだと
サーバ/インフラエンジニア養成読本 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
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
TL;DR Terraform + GitHub + CircleCI + Atlas を用いてAWSの操作を自動化した 各ツールの役割は下記のような感じ Terraform => インフラへの変更ツール GitHub => .tfファイルのバージョン管理 CircleCI => CI、Terraformをawsに対して実行 Atlas => インフラの状態を記録するterraform.tfstateの管理 インフラの継続的デリバリー - naoyaのはてなダイアリーにて、言及されていた範囲(Route53の変更、Chefの適用)をAWSの操作全体に拡大した 背景 今までの問題点 AWSの各種操作がブラウザからポチポチ業… 手作業なので誤操作に気づきにくい。事故りやすい インフラの実構成がバージョン管理出来ていない ちなみにRoute53に関してはroadworkerを用いてコードで管理済
Serverspec Serverspecを執筆されたmizzyさんからご恵贈頂きました。ありがとうございます。 本書の詳細な紹介はあんちぽさんのブログと、mizzyさんが出演したRebuildがオススメです。 Serverspecの作者がつくる、あるひとつのOSS文化 - 書評『Serverspec』 - delirious thoughts Rebuild: 75: Book Driven Development (gosukenator) 事前に断っておくと私がここで記載している「インフラエンジニア」はITインフラエンジニアの話です。 以前サーバ/インフラ徹底攻略を本ブログで紹介したあとに、 書内のある特集を執筆担当された方と話していて、 Web系インフラエンジニアがどんどん先鋭化されつつあって、この本の内容を理解出来る人ってどれくらいいるんだろうね という事を仰っていたのが非常に印
Sensu Advent Calendarに便乗して、Kaizen Platform, Inc.の2014年12月現在の監視アーキテクチャの話をちょっとしてみようと思う。 モニタリング領域 サービスを監視している領域 Pingdom Pingdom - Website Monitoring 外部ネットワークからのサービスの死活監視。アメリカ、ヨーロッパ、アジアなどの拠点からサービスの死活監視が出来るため、特定の地域からアクセス出来ない場合なのが検知出来る。 後述するstatuspage.ioとの連携で、障害を検知すると、サービスのステータス状況が自動で変わるようになっている Sensu Sensu | The open source monitoring framework. 監視フレームワーク サーバを内部ネットワークから監視するために利用 サーバのプロセス監視、サーバ間の疎通監視、エラ
いわゆる転職エントリーなので、興味無い人はそっと閉じて頂ければ幸いです。 私事ですが、6年弱勤め、シニアエンジニアとしてサービスのインフラ系業務を担当していたGMOペパボ株式会社(旧株式会社paperboy&co.)を7月末に退職して、 8月からKAIZEN platform Inc.に入社しました。 なぜKAIZEN platform Inc.を選んだのか CEO 須藤憲司さんのブログ、技術顧問である伊藤直也さんのブログや 出演していたRebuildで知っていたのもあるんですが、入社を決めたポイントをまとめると下記のような感じ。 前職でKAIZEN platform Inc.のplanBCDを導入しており、非常に高い効果がありプロダクトに関心があった 創業間も無いのに優秀なエンジニアが揃っており、技術的にもチャレンジングで尖ったことをやっていた 本気で海外進出を目指しており(会議はもちろ
https://www.digitalocean.com We’re Excited To Announce Our Singapore Datacenter (SGP1) | DigitalOcean 以前紹介した1時間1円でSSDなVPS(DigitalOcean)にシンガポール リージョンが来ていた。 早速インスタンスを立てて、自分の環境から、どのくらいのレスポンスなのか計測 [akira@dev001] $ ping -c 10 128.199.***.*** PING 128.199.***.*** (128.199.***.***) 56(84) bytes of data. 64 bytes from 128.199.***.***: icmp_seq=1 ttl=53 time=76.7 ms 64 bytes from 128.199.***.***: icmp_seq=
今年の初めくらいから個人的な技術検証にはSSDで動作が速く、1時間1円で料金が安いのと ロケーションをSan Franciscoにするとsshでもレスポンスが悪くないので、全部Digital Oceanを使っている。(徳丸先生が紹介する前から使っていたんだ!) Digital OceanについてはRebuild: 2: Rails, Redis, VPS (Kenn Ejima)の42分くらいから言及されてます。必聴です。 使ってる旧型のMacBookAirみたいな貧弱なマシンだとローカルでVM動かすとファン回りまくりとかで泣きたくなるので、Digital Oceanだと泣かずに済んで快適。 そんで今日Vagrant経由でDigital Ocean利用すると、コマンドラインから必要なときに新規インスタンス(Droplet)作って、 検証終わったら削除という手軽な使い捨て高速サーバ環境が利用
新規サービス用の監視を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を触ってる。前回のエントリを見て、@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サー
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
zolrath/wemux 新卒氏がインフラに配属になって、横に座ってOJTをやっているんですが、 説明で自分の画面と、新卒氏の画面を行ったり来たりしてアレやコレや言って作業をしているのが かなり効率が悪かったので、1ヶ月くらい前からwemuxを使って画面を共有するようにした。 screenでも画面共有出来ますが、最近私がscreen使って無いのと、 新卒研修でtmuxを使えと 強制しておいたので、wemuxを使ってます。 wemuxの特徴 tmux1.6以上が必要 単一の端末を複数人で共有出来る。 読み取り専用のmirror mode 複数人で操作ができるpair mode などの特徴があります。 wemuxの導入 導入環境はCentOS5系で、tmux1.6が既に導入済みです。 wemux自体はtmuxのwrapperなので、tmux1.6以上が必要です。 weemuxは管理サーバ(s
zsh-users/zsh-syntax-highlighting · GitHub zshで作業中にsyntax-highlightをしてくれるスクリプトがあったので導入してみた。 紹介動画をみると、どんなものだか分かります。
zsh-users/antigen 個人的には.zshrcで細かく設定しているので、利用することのないoh-my-zshですが、 oh-my-zshを利用している人をみるとなかなか便利そうで、特にpluginsが 開発も活発で、種類も豊富で便利な感じ。 oh-my-zshを利用していなくてもantigenを利用すると oh-my-zshのthemeやpluginが利用できるので導入してみた。 antigenはvimプラグインマネージャーのVundleの 影響を受けているので、Vundle使いの私には設定方法が似ていて導入もしやすかった。 antigenの導入 git cloneで持ってくるだけ。
以前、ブログに書いて以来、活用しているpsshとpscpなんですが、 付属コマンドのpslurpについてはすっかり忘れて全く利用していなかったんですが、 同僚の刺身さんが結構活用しているというのを聞いて、改めて使ってみると大変便利! Parallel sshで複数のホストへ同時にコマンドを実行する | Glide Note - グライドノート 環境はSL6.1です。 pslurpの使いどころ 複数のサーバからaccess.logなどのログ、my.cnfといった設定ファイルなどの同名ファイルを持ってくる場合 DNSラウンドロビンや、ロードバランサを利用していてアクセスログが分散している場合 通常何も考えずscpとかで持ってくるとファイルが上書きされてしまうので、 ホスト毎にファイルを分けて管理したい場合にpslurpが活躍します。 pipを利用してpsshの導入 2012年なんでeasy_i
Emacs勉強会 - Agile渋谷 paperboy.el 最近坊主にして杉作J太郎クリソツのantipopさんに そそのかされて参加したのが運の尽き… 著者の大竹智也さんをはじめ、参加者全員から「Emacs実践入門」で尻を1万回スパンキングされる勉強会でした。 「リチャードストールマンにクリソツのAV男優さんいますよねー」とか「あのAV男優さん出てくるとEmacs使いたくなりますよねー」とかで会場が盛り上がっててEmacs使いの狂気を感じた。 vim使いの私とは相容れない水と油、もしくは水とローションといった感じだった。 今回paperboy.elのlogoも作ったのでステッカーにしようかと思います。
incron :: inotify cron system webistranoでファイルをデプロイして、設定の再読み込みやサービス再起動などが必要な際に、 デプロイユーザがsudoでreloadやらrestartなどを実行しているのが、 権限的に何となく気になって、ファイルの更新を検知して 自動的にreloadやrestartする方法を模索していたら incronという良い物があったので検証。 検証環境はScientific Linux 6.2です。 実現したいこと デプロイユーザとサービス再起動ユーザの分離(sudo権限の剥奪) Nagiosの設定ファイルをデプロイしたら、Nagiosのreloadが自動でかかる Passengerのrestart.txt的な感じでreload.txtがトリガーでNagiosのreload的な incronの導入 incronをyumで導入
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く