GitHub - yuroyoro/mitm_proxy_sample: ʕ ﾟ皿ﾟ ʔ This project is a sample implementation of Proxy that sniffing request and response by "Man in The Middle".You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
GoReplayを導入して、Production環境へのリクエストを複製し、Staging環境に転送する仕組みを作った - Glide Note
結構前に作っていたんですが、いろいろと忙しくてブログに書くタイミングを失していたので年末のタイミングで紹介。 TL;DR GoReplayを利用して、Production環境のリクエストを複製し、Stagins環境、開発環境に投げる仕組みを作った インフラ構成の大きな変更無しで、手軽にProduction環境の実リクエストを複製し、開発、動作検証ができるようになった 2016年の弊社サービスのDocker化や、インフラ構成の大幅な変更、ミドルウェアのアップデート、アプリの改修時のバグ事前検知と事故防止に大いに役に立った GoReplayの説明 GoReplay Goで書かれており、バイナリを設置し、オプションを指定し実行するだけで動作する アプリが稼働しているサーバで動く。(例えばNginx+Railsが稼働しているサーバで一緒にGoReplayを動かす感じ。) libpcap を利用して
簡易リバースプロキシ「ichigo」でWebアプリ開発が捗る話 - Qiita
概要 自社サービスの開発中、必要にかられてGOで簡単なリバースプロキシツールを作った話を書いてみます。 前提 自社サービスの開発を、次のような構成で進めています。 フロントエンドとバックエンド（APIなど）をパスで振り分け /の下はフロントエンド /api/の下はAPI その他にも色々・・・ フロントエンドとバックエンドは、担当者もリポジトリも、動いているサーバも別 それぞれサーバが開発環境、本番環境とテスト環境、のように複数の環境をもっている やりたいこと 前提の環境をもって、いざ開発をしようとローカル環境を構築するとなれば、 ローカルにnginxでリバースプロキシを立てて管理するのは面倒くさい ちょっとした環境の変更があると共有がいちいち面倒くさい フロントエンド担当者がわざわざバックエンドをcloneだのpullだの面倒くさい 環境間でテストするためにわざわざnginxの設定書き換え
Slackboard〜Slackプロキシサーバ in Go〜 - Qiita
昨年末の話だけどSlackへの通知をプロキシするサーバをGoで書きました。如何せん1〜2時間で書いたので一部洗練されてない箇所があるかもしれませんが、 今年のはじめからすでに実運用をはじめています。 Slackboardの役割 SlackboardはSlackへのプロキシサーバであるslackboardとそのためのクライアントであるslackboard-cliの2つから構成されています。↓の図のようにSlackへの通知をクライアントが行うのではなく、クライアントからのリクエストを受け取ったプロキシサーバであるslackboardが行うという仕組みです。 このようにSlackへの通知を直接ではなくプロキシを介して行うのには以下のメリットがあります。 Slackへの通知設定をプロキシサーバで一元管理できる Slackへの通知リクエストをロギングできる 各サーバに散らばったSlackへの通知プロ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - pixiv/go-thumber: dynamic JPEG thumbnailing proxy written in Golang
