はてなブックマーク

Docker Machineで Error creating machine: Error in driver during machine creation: Maximum number of retries (5) exceeded で詰まった時の対応Dockerdocker-machine これなんだ MacでDocker Machineはじめた際に詰まったエラーの解決策の一つです。 エラー内容: Error creating machine: Error in driver during machine creation: Maximum number of retries (5) exceeded 環境 MacBook Pro (Retina, 13-inch, Mid 2014) VirtualBox 5.0.8r103449 とりあえずドキュメント通りにやる チュートリアル

これなんだ? Terraformをちょっと上手に使うためのテクニックというかコツです。 個人的には上手にHashicorpツールを使う能力を橋本力と呼んでます。 今回参考にしたものはこちらになります。 https://github.com/hashicorp/best-practices/ また今回動作させたコードも置いておきます。 https://github.com/a4t/terraform_001 前提 Terraformも一つの言語と思ってください。 いいコードとは、変数のスコープは短く、同じ処理を何度も書かないことです。 これはTerraformでも同様です、できるだけ綺麗なコードを書くことを意識してください。 Terraformの課題 そもそもTerraformのバージョンが違って動かない バージョンアップによって微妙な差分が発生し、何も変更ないのに変更箇所が出るケースがある

Restore to Point in Timeとは? 特定の時点への DB インスタンスの復元 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_PIT.html 勘違いとは? これでDBぶっ飛ばしちゃってもすぐ戻せるから安心だ、とか思ってた。 指定した時間にDBを一瞬で戻せるとか思ってた。 障害発生 本番運用中のものでなんかデータの整合性が合わない。 そもそものバグを除去するのも重要だが、とりあえずサービスを復旧したい Restore to Point in Time を使えば元に戻せるよ 「RDSにはですねー、Restore to Point in Timeっていう便利なものがあるんですよー」とかドヤ顔で言ってた。 よし、じゃあ30分前に戻してくれって言われたので戻そうと思ったが、実際に今まで戻したこと

Dockerでwordpressの環境構築 開発環境 ubuntu 14.04 この記事の目的 Dockerのチュートリアル終わって次何しよっかーって状態になった。 実際にちゃんと動くもの見ないとイメージつかないなと思ったので身近なwordpressを選択 Docker Hubでwordpressのコンテナあるし試してみよう https://registry.hub.docker.com/_/wordpress/ この記事でやっていること Docker Hubからwordpressのイメージ持ってくる Docker Hubからmysqlのイメージ持ってきて起動 再度wordpressを立ち上げる wordpressの動作確認 Docker Hubからwordpressのイメージ持ってくる 結構時間かかった。 3分ぐらい? $ docker pull wordpress Pulling re

Github これなんだ Fluentdを使ってMysqlのテーブルのスキーマ変更とテーブル追加、削除をフィルタリングするするプラグインを書いた Databaseのマイグレーションがしっかりできている場合必要ないかもしれない。 使い方 テーブルのスキーマ変更を検知する場合 <source> type in_mysql_table tag mysql.table host mysqlserver username username password password database database_name port 3306 interval 60 # SHOW TABLES FROM #{@database} が走るinterval </source> <filter mysql.table> type change_mysql_table host mysqlserver user

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

これはなにか AWSのLambdaを使って分散処理をします。 今回はAWS SNSのsubscribe追加をS3へのアップロードをトリガーにしたいと思います。 仕組み s3に登録したいsubscribeの情報を上げる Lambdaでその情報を解析する 解析した情報を元にSNSに登録していく この構成のメリット よくあるパターンとしてAWS SNSの登録に時間がかかってしまいメルマガやPush通知を打つのに時間がかかるというケースがあります。 この構成の場合、複数のサーバからSNSの登録が行われるため高速になります。 登録したい内容 protocol: http endpoint: http://example.com/[任意の文字] s3にアップロードする内容 var AWS = require('aws-sdk'); var sns = new AWS.SNS({ apiVersion:

これはなにか RDSのSlowLogをSlackに通知したかった。 AWSのAPIで download-db-log-file-portion があったが通知するには使い勝手が悪かったので MySQLのテーブルにSlowLogを保存して、それをFluentdからSELECT & Clear をすることにした。 この記事はMysqlの設定なので、他のDBの場合はよしなに変更してください。 使ったもの fluent-plugin-slack : https://github.com/sowawa/fluent-plugin-slack fluent-plugin-rds-slowlog : https://github.com/kenjiskywalker/fluent-plugin-rds-slowlog RDSの設定 Parameter Group slow_query_log : 1 l

この記事で検証したこと OSレベルでの起動速度の比較 インスタンスタイプでの起動速度の比較 インスタンス作成とインスタンス起動で速度に違いはでるか 結果から報告 調査した範囲内ではあるが、EC2のインスタンス起動は最短50秒前後 AmazonLinuxの起動が早かった インスタンスタイプは起動速度に影響しない stop → startの方が起動速度が早い 起動速度は運任せ ※(注記) 裏側の処理を見たわけではないので理屈ではなく体感ベース 検証 インスタンスタイプで起動速度は変わるか インスタンスタイプ t2.micro c3.xlarge c4.x8large 使用AMI ami-aa57adaa (CoreOS-alpha-653.0.0-hvm) ← CoreOSは起動早そうなので 計測方法 user-dataに以下のスクリプトを設置して検証 起動はAWS CLIからの起動 検証 t2.mi

追記(2015年06月18日) この記事はLambdaのトリガーにSNSを使えなかった時の記事です。 現在は可能ですので他の記事を参考にしてください。 Github やりたかったこと CloudWatchのアラートをSlackに飛ばしたかったので作った やりたくなかったこと 既存のやり方だとCloudWatch → 中継サーバ → Slackだった 中継サーバの管理面倒くさい そのためだけにサーバ立てるのも勿体無い 簡単なロジック説明 LambdaでCron的なことをするために、自分自身でLambdaのトリガーを発生させる CloudWatchのalertを監視する アラートあったらSlackに通知 何度も飛ぶとうるさいのでファイルロック的なことをS3上でやる ポイント Lambdaは60秒以上の処理はタイムアウトになるので60秒以内で処理は終わらせる 日本はまだLambda対応してないので