AWSで秘密定数を外部に公開せず環境変数として定義するためのGo製ツール、「ssm2env」作った
ssm2env - Environments injection tool for AWS EC2, with SSM (EC2 Parameter Store). 詳細環境ごとに異なる秘密情報をAPIに渡す際、その管理方法は、twelve-factor appにもある通りデプロイ対象のサーバー内部の環境変数として定義するべき。 ただ、自動化されたデプロイフローでは、どういった手順で秘密情報を渡せばいいか悩むことが多い。 自分が考えた範囲では、 1. AWSのSSMにTerraform経由*1でシークレットな変数を設定 2. APIのデプロイ時にSSMから特定prefixのついたパラメーターを取得 3. パラメーターを全て環境変数として読み込ませる 4. APIが起動する際に秘密情報を定数として環境変数から読み込む*1) 正確にはCircleCIの環境変数設定に事前に入れた状態で、Circ
CircleCI2.0のWorkflowsを試す
他のビルドツールで既にあった、ビルドパイプラインと考えればわかりやすいと思います。 これを導入すると何が嬉しいかというと、 ビルドの実行フェーズを複数に分けることで、どこでFailしたかなどが視覚的に掴みやすい並列にjobを実行させることで通常の同期的なビルドフローよりも効率良く回せる具体的にはbundle installとかnpm installとかを並列に回して、共有ディレクトリに結果を入れたりできる色々並列にjobを回したあと、それを待ち受けて最終的な結果を同期的に受け取ることもできるbranchや言語のバージョンによって別々でテストを回したい時などに別個かつ並列にビルドを行える外部APIにつなぎにいく時にfailした場合などでは、Rerun from failedができるので、ケースによっては全工程をなぞる必要がなくなるなどのメリットがあります。 早速自分のこれまでのcircle.
TDD of Infrastructure as Code on CircleCI 2.0
概要Docker + Ansible + ServerSpec + CircleCI 2.0でTDDなCIビルドを行う話です。 今僕が在籍している企業では、プロビジョニング周りはAWS OpsWorksで管理されており、Chefのカスタマイズレシピが適用されて、ポンっと環境が構築されます。 個人的にはChefとItamaeの運用はしたことがありますが、OpsWorksを除けばAnsibleの方がStar数も多く活発に使われていそうなのと、どうせならDockerとServerSpecを使ってポータブルなテスト環境を作ってみよう、それをCircleCI2.0で効率的に回そう、と思い立って、やってみました。 ディレクトリ構成. ├── Dockerfile ├── README.md ├── ansible │ ├── ansible.cfg │ ├── ci.yml │ ├── circlec
kazeburo/choconと、それを支えるnet/httpの実装について
【資料公開します】AWS Dev Day Tokyo 2017 にて登壇しました／choconの簡単なご紹介 - Mercari Engineering Blog こんにちは。SREの @ kazeburo です。2017年5月31日から6月2日にAWS Summit Tokyo 2017と同時に開催された「AWS Dev Day Tokyo 2017」に登壇しました。 登壇する機会をいただき、ま… 先日、というか昨日、この資料が流れてきまして、Private Networkの外部との通信を効率良く行うためのミドルウェア、choconというproxyサーバーが紹介されていました。SSL, HTTP/2を加味した上での超シンプルで高速なforward proxyサーバー実装という印象です。 使い方やAPIの叩き方は上記のリンクを参考にしていただくとして、やたらマイクロな実装でなぜこうも高速に
CircleCI2.0でのGolang APIのデプロイ設定
今在籍している企業では、最近CircleCI2.0へのアップグレードが盛んに行われている。 すでにアップグレードを体験された方からは、「は？」「速すぎてドン引き」「爆速すぎてずっと泣いてる」などとの感想が寄せられている。元気そう。 具体的に自分もAPIでバージョンを上げたら、6分半が45秒になった。 で、特定のpackageのtestだったり、インフラ周りの設定のアタッチ等なら小規模なのでなんとなくかけば導入できる。 しかしAPIとなると、意外と設定を載せているところがまだ少なかったので、API用途だとざっくりとこんな感じだよというのを書きたいと思う。 もしそこまでじゃなくていいので、簡単な設定がみたければこちらへどうぞ 全体感APIやある程度の規模のソフトウェアのCIとなると、 依存パッケージのインストールlinterでの文法チェックテストデプロイの諸々をやらなくてはならない。 色々名前
エンジニアが勉強会で発表する方法と、発表しなきゃいけない理由
TL;DR方法 -> なんかいい感じに中規模以上のものを継続的につくる 発表しなきゃいけない理由 -> 別にないけど、強いて言うならデメリットがないから。 これをまとめたきっかけ最近よくGo界隈とかでLTだの通常のトークだので参加させていただく機会があるんですが、ついこの間その活動を観測してくれた人から、 準備やらプライベート開発の時間はどうやって作るんですか？技術的に表に出るためにあと一歩欲しいけど、足りないところをどう埋めるべきですか？なんで登壇するんですか？（本質的に技術的に表に出る必要ってあるんですか）的な質問を投げかけられて、自分なりの答えを返したのでまとめる。（答えるのもおこがましい感じはしましたが） あとは、最近よく会社でエンジニアの方を採用するときに、積極的に発信する機会って増やすべきかな、そうだとしたらどうやって発信するのがいいんだろうと考えていたのもある。 準備やらプラ
継続してコードを書くということ
この度、githubへの一年間連続コミットを達成していたらしいことを確認しました。途中から平日、仕事の分も混ざっているのですが、プライベートでのコミットは毎日確認していたので、ちゃんと一年間継続できているはずです。 当初はどういうものを開発するのか定まっていなかったり、謎の練習コードばっか産まないか心配だったのですが、継続してコミットを続けていくことで、徐々に目的意識を持ってコードを書くのにも慣れてきました。 そこで、この一年でどういう考えで開発過程をたどってきたか、どういうものを開発してきたか、これからどうしたいかについて書こうと思います。 どういう考えで開発過程をたどってきたか最初は継続性のみを重視１年前と今とでは、コードを書き始める時の意識も少し変わったなと、今は思います。 １年前はどんな形であれ継続できるようにコードを書いて、たまにdotfilesいじったりとか、遅くに会社を出ると
Goで作るDBレプリケーションツール
gopli - DB replication tool to synchronize data with multi environments written in Golang. ツールの名前はgopli (go replication)で、意図どおりの名前ですね。 これは何tomlで書いた、ssh/db接続用の設定ファイルを元に、特定の環境間でデータを同期させるツールです。今の所MySQLのみ対応で、postgresqlに対応しろと言われたものの、なかなか手が回っていない状況です。 使い方は簡単で、 まず以下のように、 sshでのサーバーへの接続と、MySQLへの接続設定をtomlで書きます。 [database] [database.local] host = "localhost" management_system = "mysql" name = "app_developmen
はじめてのPodcastと、高まり
yatteiki.fmの登場によっていくらかpodcastを始める方を確認していて、元からpodcast形式で何か話すというのをやってみたかったのもあり、k0kubunくんを呼んでやることとしました。 今後も技術ネタに限らず、こういうサービスが流行っているよね、というようなテック業界全般の話をしていければなと思っています。どちらかというと開発者向けと言い切るよりも、業界の人みんなが聞けるようなものにしたいなと思っています。 はじめてのPodcastということもあって、反省や感想等をメモしておくのが今後Podcastをやる方にとっても良いかなと思い、以下に書き連ねていきます。ベースとなるノウハウの面はだいぶr7kamuraさんの記事にまとまっているので、そちらをご参照ください。私が書く内容は、これの追加情報となるところが多いです。
『みんなのGo言語【現場で使える実践テクニック】』読み終わったが、良かったです。
みんなのGo言語読み終わりました。 各位、最近レビュー書いている方は著者の方から献本されているが、僕はそんなことはなく普通に購入した。 なんか先行販売してるところが少なからずあるらしい、という情報が上記のツイートから得られた。 このツイート見たときたまたま池袋にいて、「池袋のジュンク堂ならあるのでは？」と考えて行ったら、あった。 ブックファーストにはなかった。僕は本が好きで、しょっちゅうジュンク堂行ってたがやはり素晴らしい店だとわかる。 Go言語、コミュニティに暖かさが見られ、言語としてもとっつきやすいので好きなのだけれど、いまいち実際のプロジェクトに応用されてる際のコード例とかが見れなくて悶々としてたので、「こういうライブラリ使ってますよ」みたいな話が多かったのが好印象だった。入門しつつ、痒いところを一通り掻いてもらった感がある。 もっと欲しい情報としては、「〜〜の言語から来た人にとって
クライアントはいつまでサーバーを意識するべきか ~設計議論の過程~
Facadeパターンの例として、サブシステムとしてのコンパイラーを考える。システムとしてのコンパイラーは字句解析器や構文解析器などから構成されている。これらの構成要素は、新たなコンパイラーやその他ソフトウェアを作成する上でサブシステムと… 通信処理+データ変換クラスの存在 上記のサービス層があっても、クライアントから通信するのは別のクラスに切り出さないともちろんダメ。クライアント側のモデルオブジェクトをRPCのオブジェクトに変換する、ないしレスポンスで受け取ったデータをクライアント側のデータクラスに詰めて、サービス層にコールバックで返す、みたいな処理もあるとして、それは通信処理+データ変換をしてくれるエージェント的なクラスがあった。 ということで、データの流れとしては、 View -> Controller -> Service(背後に複数のModel) -> 通信処理+ データ変換(Pr
人がやるべきではない仕事。一人のエンジニアとして。
Medium開き。はてなで自分用のブログを持っているけど、urlとかidとかがおかしいし、直したいのに直せないので、こっちに移ることにした。 僕がやるべきではないと思った仕事まず断りを入れておくと、仕事と言っても、職場の話ではない。 GoとかReduxとかReactとか、NodeとかRailsとか、OSSで見ておかなきゃなーと思った公式リポジトリをフォローした時の話。 僕は割とOSSにバンバンコミットするぜ、みたいなことに憧れつつも、なかなか自分だけのソフトウェアを作ってしまう性格で、それを治したいと思っていた。 とりあえず手始めに、各リポジトリをフォローして、各言語やソフトウェアがどんな課題を感じているのか、調べることにしようと思った。 その時に問題が発生して、なんとスパムのようにNotifyメールが来る。どれくらい凄いかというと、特にReduxなんだけど、日本時間で深夜３時くらいに、３
やっぱブロックチェーンダメっぽい
デジタル台帳「ブロックチェーン」が支える仮想通貨ビットコインを何百万人にも紹介したステファン・トーマス氏は、心変わりした。 この記事、最初見たとき釣りかと思ったけど、釣りではなく「まあそうだよね」と言う意見だった。 ここで言われてるのは 金融機関の政治問題合意形成コストの２つが課題でブロックチェーンが実戦に不向き的なこと。 １個目は人の問題なので置いとくとして、２個目が散々。 計算にマシンパワーが必要なのと、その結果を全ノードに等しく伝えるのに何日もかかる & その過程で生じた履歴がもし採用されなかったら破棄される可能性もある。 これらの点から「速くて、堅牢な、低コストの取引台帳」なんてものはないの明らかなので、登壇テーマとして用いた身なのを棚に上げながら言うと、すぐさまこの界隈は沈静化してほしい。 ハッシュ値を最も早く生成し、その結果その解答者以外の履歴はあっていようが間違っていようが場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
