はてなブックマーク

引き続きコレの件。 github.com 最初に 前のエントリの追記で、 ENV_INJECTOR_MODE に対応とか書いてたけど、どうも git push を忘れていた模様。orz… 今回の修正で大体ユースケースカバーできそうなので、もうこのままなかったことにします(ぉ 階層化パラメータ DescribeParametersでは対象のパラメータをIAMでリソース制限できないのがちょっとアレかなぁと思って 今までのenv-injectorは、inject対象リスト作成のためにあえて事前に空の環境変数を用意するようにしてました。 でもアップデートで対応された階層化されたパラメータに対してGetParametersByPathを使えば必要なパラメータだけに絞ったアクセス許可をIAMで設定できます。 というわけでenv-injectorでも対応してみました。 必要なIAMのポリシーはこんな感じ

medium.com env-injectorが「問題がある」って言われてもうた。ツライ…… というわけで言い訳エントリです。見苦しいですね。 env-injectorの作成時、空の環境変数を作らずに「DescribeParameterでパラメータ一覧ぶっこ抜いてprefixにマッチするものをinjectする」っていうのも考えたんですけど、以下のような理由からやめました。 1. DescribeParameterはIAMのポリシーで必要となる一部のパラメータだけに制限することができない。 開発環境から本番環境のパラメータ一覧が見えたり、別アプリケーションのパラメータ一覧が見えたからって「だから何？」ってハナシもありますが、 なんとなく嬉しくないかなぁ……と。 2. 意図しない環境変数をinjectしないか？ ssm側のパラメータ一覧を全部読み込むことになるので、ちょっとした確認での実行時に

AWSで動かすアプリケーションのクレデンシャル情報ってどう管理してますか？ chefやansibleでプロビジョニングしたりするにしても、平文でgit管理するのもアレだし、暗号化してコミットするのも結局扱いにくいし……と悩ましいですよね？ そんな中、こちらのクラスメソッドさんのエントリを拝見したところ dev.classmethod.jp 「AWS上で動かすアプリのクレデンシャル情報をパラメータストアから環境変数にぶっこんでくれるツールがあればイケてるんじゃね？」と思いついてしまったので、勢いでPoC的に作ってみました。 github.com 使い方は、空の環境変数用意しておいてから $ export DB_USER= $ export DB_PASSWORD= プレフィックスを指定して、env-injector経由で任意のコマンドを実行します。 $ ENV_INJECTOR_PREFIX

半年くらい前にこんな記事を書いたのですが、まあうまく行きませんでした。 okzk.hatenablog.com 頂いたブコメも試してみたんですけど、結果は芳しくなく。。。 Re: Dockerに載せたサービスをホットデプロイする - okzkメモ --stop-grace-periodの設定とDockerfileのHEARTBEATとSTOPSIGNALの設定をすれば出来るはず2016/08/17 06:19 b.hatena.ne.jp そんな中、元記事のヒトも試してみたようですけど、同じ結果に。。。 h3poteto.hatenablog.com そんな中、CVE-2016-9962も出ちゃったし、docker 1.13もリリースされたコトだし、ということでdocker 1.13でswarmモードをもう一回試してみました。 インストール後、swarm初期化 # docker swarm

はい、というわけで、前記事のworkerパターンをcontextつかったらどーなるか、についてです。 前の記事や、その元記事のソースを読んでいる前提ですので、未読の方はそちらの確認からお願いします。 さて、ざっくりとした変更の方針ですけど、以下の2点です。 contextを使うことで、workerの実装側でキャンセルできるようにする workerに渡す値はcontext経由にする。 というのをヤッツケでやってつくってみました。 以下変更点の解説です。 まず、元実装ではworkerで実行される処理がベタ書きだったのを汎用化するため、dispatcherのqueueに入れるjobをとqueueの定義を変更します。 type ( job struct { proc func(context.Context) ctx context.Context } Dispatcher struct { qu

こちらを読みました。 blog.kaneshin.co channel自体にdispatch機構があるからもっとシンプルに書けるのでは？と思って書き直したのがこちら。 コードだけぶん投げてもアレなので、あとで解説書きます。 ついでに「go1.7で標準化されたcontext使ったらどうなるか」も気力次第で書くかもしれません。 というわけで追記というか、本編というか、解説です。 channel整理 元のコードを読んでいくと、 dispatcherのqueueにjobを突っ込む dispatcherがidle状態のworkerをpoolから取り出す 同じ行で取り出したworkerのqueueにjobを渡す workerがjobを受け取って処理する。 というカンジの処理の流れになってるんですが、dispatch機構自体がchannelにはあるので、 dispatcherのqueueにjobを突っ込

こちらを拝見したところ、やりたいコトはdocker1.12のswarmモードで解決するんじゃないかなー、と思ってみたので試してみたテスト。 h3poteto.hatenablog.com とりあえず、最新版のdocker(1.12)をインストールです。 手元の環境はCentOS7なので、インストールガイドに従ってゴニョゴニョと。 んでもって、swarm初期化。 # docker swarm init 今回1台だけなので、ノード追加は行いません。 次に実験用にnginxのサービスを立ち上げます。 ポイントはimage差し替え時に「停止→起動」の順番で動くので、あらかじめレプリカ数を2にしておいて、ちゃんとローリングで切り替わるようdelayを設定することです。 # docker service create --update-delay 20s -p 80:80 --name test --

まとまりなく、何パターンか列挙します。 アプリケーションコンテナで動かす 通常ステートレスなアプリに限られると思いますけど、dockerで動かすというやり方です。 # 個人的にはdocker 1.12で組み込まれたswarmモードがすごくお手軽でよいと最近思ってます。 バイナリはstatic linkでビルドして、alpineで動かすと軽量でイイカンジです。 Dockerfileは以下みたいなカンジ FROM alpine RUN apk add --no-cache ca-certificates COPY your_app /usr/local/bin/ CMD ["your_app"] 外部サービスにssl/tls接続するのに必要なのでca-certificatesを突っ込んでます。 証明書周りを自分でなんとかするんなら、busyboxにするのもアリかと。 supervisordで動

「goで書いたアプリケーションは実行ファイルひとつコピーするだけでいいのでインスコ超ラクチン」なんて思ってたんですが、 go1.4からnetパッケージを使っているアプリケーションは、フツーにビルドするとdynamic linkになるようになってました。 $ cd /path/to/your_app $ go build $ file your_app your_app: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped そんなわけで別環境にバイナリコピーしても動かないケースが発生して超絶アタマを悩ませることになるのですが、 そんなときは以下のようにbuildすればstatic linkになってくれるようです。 $ go build

mattnさんのエントリに触発されて、某所で使用したちょっと変わったgolangのチャンネルの使い方をご紹介します。 mattn.kaoriya.net 特定の処理の並列度をある程度までに抑えたい、みたいなコトありますよね？ 例えばCPUヘビーな処理の並列数をたかだかコア数くらいまでに抑えたい、とか。 そんなときはバッファ付きチャンネルを用意しておいて、当該処理の前後でそのチャンネルにwrite/readをすることで、セマフォ的な制御ができます。 以下のようなカンジです。 package main import ( "fmt" "sync" "time" ) var ch chan int = make(chan int, 4) // 並列度を4に制限 func heavyFunc(i int) { ch <- 1 // チャンネルのバッファがイッパイになっていたら、ブロックする defe

以下の手順でハマった。対象のバージョンは5.6.27 あるslaveでMySQLを停止してコールドバックアップをとって起動 バックアップをコピって別サーバでslaveを構築 MySQL起動したら、 元サーバ のio_runningが停止。 原因はauto.cnfを消してなかったのでserver_uuidが衝突してしまったから。orz... # server_uuidは5.6からなので、完全にやらかしてもうた。 ちなみにshow slave statusで出てたエラーメッセージは以下の様なカンジ A slave with the same server_uuid as this slave has connected to the master 教訓 コールドバックアップからslaveを作る際はauto.cnfは消そう。 もしくはバックアップからそもそもauto.cnfを除外しよう。 愚痴

golangでのtickerのサンプルで以下のようにgoroutine内でrangeを使ってforループを回すのをよく見かけます。 package main import "time" import "fmt" func main() { ticker := time.NewTicker(10 * time.Millisecond) go func() { for t := range ticker.C { fmt.Println("Tick at", t) } }() time.Sleep(35 * time.Millisecond) ticker.Stop() } コレ、以下のようにちょっと変更して実行してみましょう。 package main import "time" import "fmt" func main() { ticker := time.NewTicker(10 *