Terraformでssm parameterを管理するのを試す - tjinjin's blog
About 深夜テンションでTerraformでssmを管理できるのかなって思って試しました。 環境 terraform v0.10.4 terraform-provider-aws_v0.1.4 事前設定 今回はsharedCredential方式を使うので下記のように設定します。（~/.aws/credentialsが利用されます） # provider.tf provider aws { region = "ap-northeast-1" profile = "default" } すでに設定されているパラメータを参照する dataを使って既存の設定が読み込めるか確認します。 事前にfooというkeyのパラメータを登録しておきました。 # existence_parameter.tf data "aws_ssm_parameter" "foo" { name = "foo" } ou
Mackerel Meetup #9 Tokyoに参加しました - tjinjin's blog
About Mackerel Meetup #9 Tokyoにブログ枠で参加したので書きます！ 会場 めっちゃシャレオツでした！ 有名アーティストのサインとか飾ってあった！（写真NGだったので心に留めておきます😇） 地の文は走り書きなので一部間違っていたりわかりにくい部分があります。気になる部分はスライド（公開されれば）もしくは今後のアナウンスをご確認下さい。 The 2017 Mackerel Product Roadmap. 株式会社はてな Mackerel プロデューサー 杉山広通(id:sugiyama88) 会場がめっちゃシャレオツ agentインストール型のSaaSサービス ユーザは管理画面ベースで設定することができて便利 mackerelってスマホでも見れるらしい（知らなかった ワンライナーでインストールできてめっちゃ便利（最近かな “最小のルールが最高の利便性を"目指して
pull型デプロイとAutoScallingの相性が結構よかった話 - tjinjin's blog
About 私が担当しているインフラ環境で先日インスタンス障害がありましたが、pull型デプロイにしていたからか自動でインスタンスが復旧できたので嬉しさのあまり記事にしてみます。 About 技術スタック AutoScalingにした際のゴールデンイメージ問題 pull型デプロイについて インスタンス起動の流れ この前起きた障害時の流れ この構成のデメリット まとめ 参考 技術スタック consul + stretcher Autoscaling AutoScalingにした際のゴールデンイメージ問題 AutoScallingをさせるにはアプリが全部入りのAMIが必要です（AMIを起動させた時点でサービスインできる状態）。ただ、更新が多いアプリだと更新の度にAMIを作るの時間かかりますよね…。1日10回デプロイするなんてことになったら、CIでやるにしろそれなりの時間がかかるのでかなり面倒く
転職してほぼ1年が経ったので振り返る - tjinjin's blog
フィードフォースエンジニア Advent Calendar 2015 の19日目の記事です。 昨日は task 先生の プレゼント交換アプリを作っている話 | task blog という記事でした！ぜひ完成させて欲しいですね！ 私、実は フィードフォース という会社でインフラを担当してます。敢えて今までブログで社名出して来なかったのですが、1年目で辞めずに済みそうなので名乗ってみました。この記事では1年間働いてみて学んできたことを振り返りたいなと思います。ポエムな内容多めです！面白く無いです！！！！！！１！ 1月〜3月 主な出来事 入社 初エンジニアブログ CircleCI + DockerでサーバCI始めました | feedforce Engineers' blog 主に触った技術 chef serverspec docker 証明書・ドメインの管理とか 考えていたこと 意気揚々と入社し
Rundeckを社内isuconのキューとして利用した話 - tjinjin's blog
先日、社内でisuconを開催した際にRundeckを利用したお話です。 背景 弊社内で、isucon5の予選問題を個人戦でやってみようということになり、私が環境の準備をしました。用意されているイメージを元にインスタンスを起動し、公開されているスクリプトを使ってインスタンス内でスコアが取得できることを確認しました。 しかし、開催日前日にとある若手エンジニアに「ベンチ実行するときにもCPUとか使うし、ベンチ対象サーバとベンチ実行サーバは分けて実行しないと正確な値取れないんじゃないですか^^」と言われて急遽リモートからベンチマークを実行できる環境を作ることになりました。 戦略 困ったものの、リモートから各インスタンスにベンチマークを実行するパターンをいくつか考えてみました。 isucon5の予選相当の環境を用意する 準備が大変そう。キュー保存用のRDBMS用意しないといけないし。ということで今
DockerHub + CircleCIを使ったCI環境を作ってみた〜導入編 - tjinjin's blog
CircleCIを使い出していろいろ課題を感じてきたので、いろいろ試してみました。 前提 CircleCIでのテストでは、vagrant-awsを使いEC2インスタンスを立ててそこに対してserverのテストを行っていました。 課題 今勤めている先ではCircleCIを使ってCI環境を作っていますが、利用が増えて待ち行列が発生。chefのcookに時間が一番かかっているものの、EC2インスタンスの起動やchefクライアントのインストールに時間がかかってます。ここをどうにかしたい。 ciにわざわざAWS使う必要ないのでは（お金も少しだけかかるし） （単純に）docker使いたい。 ということでCircleCI上でdockerコンテナを使えないか試してみました。 CircleCIでDockerを使うためにやったこと Dockerfileの作成。 # Dockerfile FROM centos
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
