Kubernatesにおけるsecretはとても便利だが、どのようにrepositoryの中で管理していのかが悩ましい。 Yamlファイルを平分で書いておくわけにもいかない。 そんなときに便利なのが shyiko/kubesec kubesecを使うと、yamlの構造を保持した上で、secret化したい値をPGP, AWS KMS, GCP KMSで暗号化してくれる便利ツール。 更新するときは復号化した標準出力をkubectlに食わせてあげるだけで良い。 Google KMSで暗号化し、secretの更新ができるか早速利用してみる Create secret 仮に passwrod: password というkey-valueを暗号化するとする % echo -n 'password' | base64 cGFzc3dvcmQK 上記を利用したsecretを作成します apiVersion:v1kind:Secretmetadata:name:sampletype:Opaquedata:password:cGFzc3dvcmQK Prepare KMS https://cloud.google.com/kms/docs/quickstart gcloud auth application-default login gcloud kms keyrings create test --location global gcloud kms keys create sample --location global --keyring test --purpose encryption gcloud kms keys list --location global --keyring test NAME PURPOSE LABELS PRIMARY_ID PRIMARY_STATE projects/threetreeslight/locations/global/keyRings/test/cryptoKeys/sample ENCRYPT_DECRYPT 1 ENABLED うん、期待するkeyringとkeyが作られている。 ... Read more

blogなどにかっこいい感じにterminalの情報を上げたいときがある。 この方法について、いくつかの方法があったので紹介したい。 mjording/ttyrec おなじみttyrec, ttyplay Usage # Install brew install ttyrec # rec start with: ttyrec demo.tty # stop by exit tty # reply with: ttyplay demo.tty asciinema よく見るasciinema. ホスティングもコマンド一発なのでホント楽。 ちなみにpecoとかfzf噛むとその画面は記録されない :sweet_face: Usage brew install asciinema # Start recording with: asciinema rec # Upload operation with: asciinema upload faressoft/terminalizer node製のterminal操作記録ツール。 操作をyamlで書き出してあとから編集できたり、いろいろ嬉しい。 anigifや外部の動画サービスに書き出しが気楽なのも良い。 Usage npm install -g terminalizer terminalizer init# Start recording with: terminalizer record demo # Generate anigif with: terminalizer render demo こんな

最近巷でIstioに代表されるservice meshの話を聞くようになりました。 そんなservice mesh、全く理解できていない。 Phil Calçado - Pattern: Service Mesh などをヒントに、なぜservice meshというものが必要となってきたのか理解を深めていきます。 コンピューターサイエンスをちゃんとやってきたプログラマーではないので、誤っている可能性は多分にあるので、その点は理解ください。 Distributed System 世の中のサービスの大半は、複雑度の違いはあれど分散システムとして構成されることを前提とされている。 A distributed system is a system whose components are located on different networked computers, which then communicate and coordinate their actions by passing messages to one other とあるように、分散システムとは、ネットワーク上の異なるコンピュータ上にコンポーネントが配置されているシステムとして考えて良い。 例えば、AWS上のマネージドサービスを使っていたら分散システムであるといえる。 service A,B が存在し、それが通信してやりとりする分散システムを例になぜ必要となるのか考えを深めていく。 牧歌的な分散システム サービス間はメッセージをやりとりするための、通信のスタックがあり、その通信スタックを経由してservice間の通信を行う これで良くない？と思うかもしれないが、分散システムには気をつけなければならないことはとても多い。 Fallacies of distributed computing L Peter DeutschやSun Microsystemsの他の人が書いた、「分散アプリケーションを初めて使うプログラマは常に間違っている」という話があるようです。 Fallacies of distributed computing ネットワークは落ちない 遅延はゼロ 無限の帯域 セキュア 変更されないトポロジ 一人の管理者 転送コストはゼロ 均一なネットワーク 一見するととても当たり前のことを書いてあるように見えるのですが、上記に関わる対策がアプリケーションコードとして実装できているか？というと、そうでもありません。 ... Read more

GKE上のnode logging aggregator fluentdのversionup fluentd-0.12.40 -> 1.12系 (0.14系でも) なぜ？ fluentdの remote_syslog output plugin が0.14系以上じゃないと TCP+TLS通信をサポートしていないから 0.12系にbackportとかやってられない 掘っていく fluentd-gcpなるimageはどこで管理されているのか？ kubernates/kubernates From kubernetes/kubernetes - cluster/addons/fluentd-gcp/fluentd-gcp-image Collecting Docker Log Files with Fluentd and sending to GCP. The image was moved to the new location. ほほぉ。 kubernates/contrib From kubernetes/contrib - fluentd/fluentd-gcp-image This project has been moved to GoogleCloudPlatform/k8s-stackdriver:fluentd-gcp-image@master ほほぉ。 ここにある GoogleCloudPlatform/k8s-stackdriver - fluentd-gcp-image もちろん最新の状態も 0.12系 source 'https://rubygems.org' gem 'fluentd', '~>0. ... Read more

やっと、やっとです。 cookpadなど名だたる会社のように、自社tech meetupを開催することができました 🎉 全体では40名近い方にも参加いただき、内容的にも盛り上がり、個人的にはとても楽しかったです :sparks Whats Repro Tech Meetup Repro Tech Meetupは、スタートアップにおける技術領域での失敗を少しでも防ぐようノウハウを共有することを目的とするミートアップです。 Reproで過去選択した技術の失敗談や、それをどうやって盛り返してきたのか共有 Reproの今を支える技術や知見を共有 ゲストを呼びReproで利用する・している技術について学ぶ Repro は、5,000以上の世界中にあるアプリに利用されるマーケティングオートメーションツールを提供する会社です。 数千万DAUのアクセスや行動ログを基にした柔軟な分析ワークロードを実現し、毎日億を超えるpush配信などのマーケティング施策の実施を支援しています。 Prepare 受付にはReproグッツも！四角いのはメモ帳です 👀 お酒を飲みながら聞ける！ 人もいっぱい！ 今回のテーマはDocker あの docker によるアプリケーション開発環境構築ガイドを著者の櫻井さんにも登壇いただきました! 当日のTwitterの様子は以下を御覧ください togetter - Repro Tech Meetup #1 Docker まとめ RettyにおけるDocker活用のこれまでとこれから by 櫻井洋一郎 お酒飲んでるところを映してしまってすいません 😅 Rettyさんは2014年から機械学習基盤にdockerを使っているのすごい。 ReproとECSの今と昔 by kei_q ECSとの戦い。ECS進化してきたなーとしみじみ感じます。 個人サービスをFargateに移行したよ by hatappi 昔の自分に伝えたい容量回復のためのDockerの仕組み by ksk1030 ECS運用ノウハウ by naomichi => https://github.com/metaps/genova systemd-nspawnは便利らしい by threetreeslight 時間が余ったので私もLT打ち込んだっ！当日にっ！！！ 次回も がんばっていきますので、よければぜひご参加ください 🎉 ... Read more

2年ぶりに開催したshinjuku.aar が前回。 思ったより良い雰囲気だったこともあり、今月もshinjuku.aarを開催 🎉 shinjuku.aarとは？ 発表ごとにディスカッションタイムを設けているのが特徴的な勉強会です :) 以下が発表。 Background Execution LimitsのAndroid Pの変更点？ by konyavic めっちゃ面白かったです。 観測されない変更。ログを目diffして見つけていくとかヤバイ。超やばい。 もう胆力の塊。 Visual Studio App Centerで始めるCI/CD by nakasho Visual Studio App Centerで始めるCI/CD from Shinya Nakajima microsoftの本気を見た！ ここまで使い勝手良いのであれば、SDK用の社内のCIを移管するのも有りなのかもしれない 🤔 1つのアプリに複数のプッシュ通知サービスを入れた by takehiroxy 資料がアップされていないのが残念。 foregroundとbackgroundでreceiverの挙動が異なるというのに、まじか、、、という衝撃でした。 RxIdlerを使ってみた話 by youmeee https://github.com/square/RxIdler Reactive Programmingしているときの待ち合わせをちゃんとやってくれる子 これはテストが捗る International Obfuscated Kotlin Contest by lee 少し時間が余ったのでredditなりから面白いネタを leeさんが発表! https://www.reddit.com/r/androiddev/comments/91h2vi/international_obfuscated_kotlin_contest/ Hallo worldを出力するプログラムを以下にkotlinで汚く書くかというアレですねｗ https://github.com/fractalwrench/iokk やっぱ最後は文字コード使って頑張っていくんですね。趣深い。

私はReproで VP of Engineeringというお仕事をしているわけですが、エンジニアだったことも含めて人に関わる領域はわからないことが多いんです。 もう試行錯誤しかありません。答え、教えてくれませんか？ そんな思い満々なので、startupのHR業界盛り上げるためにもイベント作ってみました 👀 開催の雰囲気 https://www.wantedly.com/companies/dip/post_articles/127060 https://www.wantedly.com/companies/peraichi6/post_articles/127106 写真は小林さんの記事から拝借させていただきました。感謝 🙏 What’s Hacking HR! スタートアップにおける人事担当者のロールは多岐にわたります。 採用から労務・総務、果ては経理、営業事務に渡るまで幅広いものです。 しかし、私たち人事担当者のリソースも才能も有限です。 そのため、業務が多岐にわたる人事担当者は、会社の置かれる状況を正しく把握し、今会社の成長のドライバーは何であるか見極め、フォーカスし行動することが求められます。 そんなの正しく判断するのは無理ゲーです。 会社を経営でもしたことがない限りできそうもありません。 そのため、Hacking HR! ではスタートアップにおける人事担当者の活動をハックし、tipsを共有・ディスカッションするとともに、明日も元気に一歩前進できるようにすることを目的としています。 Theme : Hack Recruiting Media! 採用のためのダイレクト・リクルーティングやリファラルを頑張っていく空気づくり、採用のためのイベント開催はとても大変です。MP（多大な精神力）と時間を消費します。 我々HRに時間はない。そんなときに思いつくのは転職したい人が自ら進んで応募してくれるメディアです。 この銀の弾丸っぽいやつを、本当に銀の弾丸にすべく知見を貯めるミートアップを開催しました。 メディアをたくさん使ってみた by Repro株式会社 畑中 五月 GitPitch Presents: github/h-satsukiy/slides コンパクトに話がまとまっていてめっちゃいい。 Wantedly月間300エントリーを獲得し、1年で部署のインターンを4人から40人に増やした話 by ディップ株式会社 小林 宥太 wantedlyを活かすには圧倒的に画像とfeed投稿大事！ エンジニア採用担当者が考える負けないためのメディア戦略 by 株式会社Gunosy 猪飼 直史 負けない戦略。失敗しなければあとは量を増やせばいいだけといういい話。 元agentのikaiさんの面談プロセス話のほうに意識持っていかれそうでした。 狙った相手を逃さない、ダイレクトリクルーティングの極意 by 株式会社アトラエ Customer Success 平井 雅史 様 以下にヒットするDMを打つかという 採用広報ツールとしてWantedlyを使い倒す方法 by ウォンテッドリー株式会社 Customer Success 佐藤 太亮 様 ソーシングどうするのか、部門採用しているのどうなるのか？めっちゃためになる話 ... Read more

stackdriver -> gcs, bqすればよいのでは？ nginx prometheus grafana | | | ------------------- ||| node logging agent(fluentd) ||| stack driver | cloud pubsub | ------------------- | | | bigquery gcs papertrail/stackdriver concern data lost on fluentd node logging agentであるfluentdを終了するときにはいくつか気をつけなければいけないことがある buffer lost fluentd containerを単純にSTOPすると以下のような問題があります。 SIGTERMがcontainerに送られる container内で稼働するfluentdにSIGTERMが伝搬する fluentdがmemory bufferのflushを試みる 失敗してもretryしない この問題を解決するためには以下のような処理をする必要がある。 データの受付を停止 bufferのflushが完了していることを確認 終了 😇 see also: Fluentd’s Signal Handling forwarder data lost 直接データを送信している場合は、接続先のfluentdがdownしても問題ない状態を作らなければいけない service discoveryを行い、生存しているlogging agentに自動で再接続されなければいけない retryが適切になされなければいけない その間、可能であれば処理が継続できなければい tips: how to resolve fluentdのHA構成にておくことで、送信元の問題の解決も比較的容易である。 ... Read more

kubernatesのcluster上でlog集約をどうするべきか考えてみます。 nginx prometheus grafana | | | ------------------- | ココらへんどうしよう？ | ------------------- | | | bigquery gcs papertrail/stackdriver | spark(data proc) default logging architecutre on kubernates まず、kubernates標準ではどのようなログ集約を行っているのか調べます。 The easiest and most embraced logging method for containerized applications is to write to the standard output and standard error streams. … By default, if a container restarts, the kubelet keeps one terminated container with its logs. If a pod is evicted from the node, all corresponding containers are also evicted, along with their logs. ... Read more

GKE上でのblog運用や監視が大分形になってきました。 次に目指すところ ここから以下のようなデータパイプラインとログの分析基盤を作って行きたいと思います。 nginx prometheus grafana | | | ------------------- | fluentd cluster | ------------------- | | | bigquery gcs papertrail | spark(data proc) TODOは以下のようなイメージです。 nginx logをLTSVに変える 自前のfluentd clusterを準備する fluentd clusterからbigquery, gcs, papertrailにfunoutするようにする nginx, prometheus, grafanaなどの稼働するcontainerのlog driverを上記で準備したものに変える google analyticsのデータをembulkを利用した定期バッチで GCSやbigqueryにpertitioningされた形で格納する 上記のログを元に、spark(data proc)を回していい感じに分析できるようにする mllibを使って遊ぶ 今回はその中での一つ目に着手します。 What ltsv 改めてltsvについてまとめます。 http://ltsv.org/ Labeled Tab-separated Values (LTSV) format is a variant of Tab-separated Values (TSV). you can parse each line by spliting with TAB (like original TSV format) easily, and extend any fields with unique labels in no particular order. ... Read more