サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
円安とは
okzk.hatenablog.com
最近OpenID ConnectのCIBAフローを実装する機会があったので、その感想をメモっときます。 そもそもCIBAフローって何? authleteの川崎さんのqiitaがマジ詳しいです。 qiita.com 認可コードフローなどの通常のフローはリダイレクトでトークンのやりとりを行うのでブラウザ上で動くことが前提となりますが、CIBAはブラウザ以外での認証リクエストを受け付けることができるので、いろんなとこに応用が効くと思ってます。 以下、川崎さんの記事を読んだりして、CIBAフローの雰囲気を理解した方向けに、実装してみた感想をカンタンにまとめます。 サーバサイドの実装 すでにOpenID Connectの実装があるんなら、POLLモードで最低限のCIBAフローそのものの実装はそこまで難しくないです。 tokenエンドポイント以外は新規実装でよいので既存の設定の整合性を考えなくてよいで
okzk.hatenablog.com こちらのgolangのstatic link化に関する2年前の記事なのですが、先月こんなコメントをいただきました。 golangで書いたアプリケーションのstatic link化 - okzkメモ そのtagを指定するとどう動く、ってのがイマイチわかりにくい。netパッケージだとnetgoまたはnetcgoを指定することで名前解決の方法が変わったりするし。2018/03/27 18:36 b.hatena.ne.jp そんなわけでビルド時にtagでnetgo指定したら、何が起こるかというハナシです。 あまり知られてないと思いますが、golangのDNSの名前解決の方法が以下の2種類があります。 libcの getaddrinfo を使う pure goの実装 前者のlibcの getaddrinfo を使う場合はdynamic linkになってしまい
SSRFそのものの解説は、最近公開されたはせがわようすけさんのスライドが詳しいので、そちらを見ていただくとして、、、 speakerdeck.com 最近では実際の攻撃事例もでてきている、ということで、ついカッとなってgolangのライブラリを作ってみました。 github.com 使い方は antissrf.Client() で *http.Client が帰ってくるのでそれをフツーに使うだけというカンタン仕様です。 プライベートアドレスとかループバックアドレスとかリンクローカルアドレスにアクセスしようとするとerrorが帰ってきます。 var client = antissrf.Client() func main() { // errが帰る _, err := client.Get("http://169.254.169.254/") } antissrf.Client() は *n
本日Security Engineering Casual Talks #1というイベントがあったんですが、そこでKMSの利用について喋ってきました。 内容的にはenv-injectorの利用につながるアレコレだったりするんで、個人的には目新しい内容というわけではなかったんですが、これで世の中からDBパスワードとか他サービスのアクセストークンとかがそのままgithubのリポジトリに保存されるケースが少しでも減ればよいなぁ、と思っています。 なお、会場では全く関係ない某社のサービスのTシャツを着ていたんですが、誰からツッコまれませんでした。カナシミー (追記) 某所からプレゼンをiframeで貼ればいいのに、、、という電波を受け取ったので対応 某所から「"復号化"ではなく"復号"だろ、ボケ」というツッコミがきちゃいました。そのとおりだと思います。ゴメンナサイ。プレゼン資料を修正するのは面倒な
コチラの記事の感想というかなんというか、です。 Goでスケールする実装を書く - GolangRdyJp なんつーか、概ね伝えたいコトは同意できるんですけど、用語の誤用っぽいモノがあってスッとアタマに入ってこないのです。 # ワタシの解説がアヤシイ場合は是非コメント等でツッコんでいただけるとウレシイです! "冪等性"について ある実装が他のコアやプロセス、他のホストで稼働中の場合、 どこにある実装で処理を実行したとしても 引き渡す情報が同じなら結果も同じであることを「べき等」であるという。 このような実装の場合、いくつもその実装が動く環境を用意しておいて、 順番に使われていない実装に丸投げするように分散させることで スケールして大きく性能を確保できる。 冪等性って「繰り返し同じ処理を行っても、結果が一緒」ってことで、数学的にいうとだし、 chefとかでいうと「とある状態のサーバ」に何度「c
AWS Secrets Managerリリースされましたね。 そんなわけでenv-injectorをSecrets Managerに対応させました。 ダウンロードはgithubのリリースページからどうぞ。 使い方は、こんなカンジでSecretが登録されている状態で $ aws secretsmanager get-secret-value --secret-id prd/db --query SecretString --output text {"DB_USER":"scott","DB_PASSWORD":"tiger"} ENV_INJECTOR_SECRET_NAME を指定して任意のコマンド実行すれば、環境変数が設定された状態でそのコマンドが実行できます。 $ export ENV_INJECTOR_SECRET_NAME=prd/db $ env-injector printe
id:kakku22 兄やんから「Mackerel Meetupで発表することになったぜ」と連絡をもらったのですが、そのハナシの流れで、 「コンテナのメトリクスを取るイケてるやり方をブログにしてちょ」といわれてしまったので PoCレベルで恐縮ですがエントリにまとめます。 前回までのおさらい ECSホストにMackerelエージェントいれて、そのホストで動いているメトリクスを収集するというカンジです。 kakakakakku.hatenablog.com とりあえずはまあ動くとはいえ、なんとも微妙な点としては以下の通り シェル芸が必要 ダッシュボード作りこみが必要 ECSホストでMackerelのagentインスコする必要がある(Fargateの場合どーすんの) 今回のやり方 サイドカーコンテナでメトリクス収集するエージェントを動かしておく プラグインがエージェントにアクセスしてまとめてカス
引き続きコレの件。 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
当方、現在の担当業務的にMackerelを両手で数えられるくらいのサーバにしか導入しておらず、しかも初期に設定をしたあとは絶賛放置中という超ライトユーザなのですが、先日なんの因果か他部署の方から「ECRのダイナミックポートマッピングしているときのコンテナのメトリクス取るのどうすればええん?」という相談をうけてしまいました。 完全無欠のMackerel情弱としては、極々テキトーなやり取りをせざるを得なかったのですが、なんだかそれなりにイイ感じまとまったみたいです。 kakakakakku.hatenablog.com kakakakakku.hatenablog.com 結論、id:kakku22 さんカッケー。 まあそれだけだとアレなわけで、事情があって歯牙にもかけてもらえなかった別の方法をこのエントリでは書いてみようと思います。 ざっくり提案したのは以下のようなやり方。なお当方テキトーな
Symantecの証明書でアレコレざわついているので、自分用にまとめます。 経緯等 以下にまとまっていまるので省略。 notchained.hatenablog.com 何がおこるか? https://github.com/sleevi/explainer/blob/master/README.md ざっくりまとめると以下の2点 該当の証明書の有効期限を短いモノとして取り扱う(最終的には最大279日とみなす) 該当の証明書はDomain Validatedとして扱う(EV証明書がEV証明書として扱われなくなる) 「該当の証明書」って? https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/README.md 証明書チェーンのルートCAの証明書が ここになければセーフ subCAで発行した証
golangで作った長時間動かすアプリで「goroutineリークやメモリリークがないか知りたい」とか「GCの影響がどの程度か知りたい」とかないですか?ありますよね? そのためのログをダラダラ出力するためのライブラリを公開しました。 # 元々はクローズドなトコで作ったモノを、公開のため完全フルスクラッチで書きなおしてます。 github.com 使い方はmainのアタマとかに適当に組み込むだけです。 func main() { // 1分ごとにログにjson出力 t := stats.SchedulePeriodically(time.Minute, func(s *stats.Stats) { log.Println(s) }) defer t.Stop() // あと本来の処理を…… } # 標準ロガーがアレなら、お好みのロガー使ってください。 String()で生成されるjsonはそ
会社でかいた記事のはてブのツッコミのフォローをゆるゆる書いてみるテスト 記事中取り消し線多くてゴメンナサイ。 理解が乏しく恐縮なのですがこれは、CSSスプライトみたいなことをアーカイブファイルとインデックスファイルで実現した、という理解でよろしいのでしょうか。 - ngsw のコメント / はてなブックマーク CSSスプライトみたいに「ページ表示に必要な複数の画像を効率よく配信する方法」ではなく、「それほどアクセス多くない画像ファイルをストレージ上にどう保存するか」という観点で読んで頂けると幸いです。 Swiftはオブジェクトが増えると書き込みパフォーマンスが下がる話、GREEでも言ってたけどやっぱり厳しいんだな。/ Log structured files 自前実装は気合入ってる。 - ono_matope のコメント / はてなブックマーク オンラインで更新があるわけではないので記事上
半年くらい前にこんな記事を書いたのですが、まあうまく行きませんでした。 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
みなさん「みんなのGo言語」は予約ポチりましたか? 私はポチりました! そんな「みんなのGo言語」の著者の一人であるid:lestrrat さんからの前エントリに対してマサカリが飛んできてます。 workerパターンをcontext化してみたら…… - okzkメモ[golang] context.Contextを揮発性のないものでラップして持つのはよくないと思う。このほうがよりGoっぽいと思うが、どうだろう https://gist.github.com/lestrrat/c9b78369cf9b9c5d9b0c909ed1e2452e2016/08/23 18:34 コメント内のgistのリンクはこちら ちょっと時間あいちゃいましたけど、これについて思ったことを2点ほど…… まずはcontext関係ないとこから…… contextの使い方へのツッコミなのにいきなりcontextとは無関
はい、というわけで、前記事の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 *
今更感あるけど、以下の補足。 kakerukaeru.hatenablog.com なお、対象のMySQLのバージョンは5.6.26と5.6.27です。 といってもオペレーション自体は特記することもなくて、以下のページをよく読んでそのままやればダイジョウブです。カンタンカンタン。 http://dev.mysql.com/doc/refman/5.6/en/tablespace-copying.html 以下、注意点、というかハマったところ。 複数のテーブルをまとめてエキスポートする場合 FLUSH TABLESは以下のように複数のテーブルをまとめることが可能。 FLUSH TABLES t1, t2, t3, t4 FOR EXPORT; # (ファイルコピーしてから) UNLOCK TABLES; 同一セッション内で複数に分けてテーブルをLOCKすることはできないので、以下はダメ。 F
前のエントリでは各ノードのメモリ管理について書いたので、次にクラスタ全体のリソース管理として CapacitySchedulerについてのメモです。 なお、CDH4.1.2で試した結果ですので、最新のバージョンとは(ry CapacitySchedulerについて クラスタ上では同時に様々なmapreduceを実行するのが普通だと思います。 CapacitySchedulerを利用すると、各jobごとに重要度に応じて、柔軟なリソース割り当てを行うことができます。 詳細は以下を確認してください。 http://archive.cloudera.com/cdh4/cdh/4/hadoop/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html 以下、微妙に気になったトコをメモしていきます。 rootのcapacity設定は必須 自明なのでなくても
yarnはmr1と色々と変わっているのですが、まず各ノードにおけるメモリの設定についてまとめます。 なお、CDH4.1.2で試した結果ですので、最新のバージョンとは挙動が異なる可能性があります。 # まとめるのをサボっていた結果既にCDH4.2がリリースされています(汗 メモリ管理の基本 yarnではapplication master(以下AM)やmapper, reducerを総称して「コンテナ」と呼び、「各コンテナが利用すると想定する物理メモリ量」をmapred-site.xmlの以下の項目で設定します。 yarn.app.mapreduce.am.resource.mb => AMが使用するとするメモリ mapreduce.map.memory.mb => mapperが使用するとするメモリ mapreduce.reduce.memory.mb => reducerが使用するとする
このページを最初にブックマークしてみませんか?
『okzk.hatenablog.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く