remote_addrとかx-forwarded-forとかx-real-ipとか - Carpe Diem
背景 ECSでNginxのコンテナをプロキシとして立てたところ、APIサーバのアクセスログのクライアントIPがNginxのコンテナIPになっていたのでその修正をしたのがきっかけです。 環境 Nginx 1.10.2 Docker1.12.1 構成 Client -> ELB -> Nginx -> API という構成とします。 ネットでよく見る情報 set_real_ip_from 172.31.0.0/16; real_ip_header X-Forwarded-For; を追加する、とか proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; を追加する、とかどれがどれだか分かりにくいので１つ１つ説明していきます。 用語説明 remote_
【AWS x S3 x IAM】アプリから S3 にデータをアップロードするときの IAM 権限設定 - Qiita
やりたいこと アプリケーションからS3にデータをアップロードする 特定の bucket への参照権限だけ，アプリケーションに付与したい 気づいたら S3 の画面UIがガラッと変わっていたので，その辺もまとめなおした． 今回は，Rails X carrierwave で動作確認したが，SDKが使えるアプリケーションなら何にでも適用可能． S3 の設定 bucket作成 誰も取得していない固有バケット名を指定する． 2. Set properties と 3. Set permissions は後で設定するので，一旦 Create をクリックして bucket を作成する． CORS configuration 一覧から作成した bucket を選択し，右側メニューの Permissions を選択 サンプルの policy が設定されているので，下記の通り書き換え，保存する． 保存後 <CO
ECSを運用している中でAWSのVPCのCIDRを変えずに使用するIPアドレス減らしていく方法
そこで、開発環境やステージング環境は可用性を妥協できるのでSpot Fleetで安いお値段で強いインスタンスをたてるという方針にして、これでインスタンスの個数を大分減らすことができました。 対応策2: ALBのルールベースの振り分けを使う ECSのサービスは基本的にロードバランサーがないと使えない仕組みになってます。『基本的』と言ったのは、なくても動くっちゃ動くという意味です。ただし、動的ポートマッピングされたコンテナのヘルスチェックやサービスディスカバリなど、現状ロードバランサーがやってくれることを自分でこなす必要があります。 ECSで運用する場合、通常httpやhttpsで通信するサービスはL7のロードバランサーであるALBを使うわけですが、今まではALB : ECS service = 1 : 1の関係で作っていました。しかしこれでは、apiやadminみたいなサービスが増えるたびに
monitで監視しているプロセスをunmonitorしてメンテナンスする - Qiita
monitでプロセス監視（落ちてたら再起動する）設定をしていると、メンテナンス時に勝手に立ち上げてくれてしまったり、逆に面倒な事が起きるので、その場合の手順を纏めておきます。 参考：CentOS 6.5にmonitをインストールしてプロセス監視をする 前提条件は、monitのWebインタフェースが空いていて、コマンドからのモニター設定が可能になっている事です。 ※コマンドからじゃなくて直接Webでunmonitor/monitorするのでもいいのだけども、大概メンテナンスするときってコマンドライン使っていると思うので、そのまま出来た方が便利 ここでは、仮にvarnishのメンテナンス(設定変更とかバージョンアップとか)で監視を停止する場合を想定します。 監視状況の確認(status/summary) $ sudo service varnish status varnishd (pid 1
数百GBのデータをMySQLからBigQueryへ同期する | メルカリエンジニアリング
SRE所属の @siroken3 です。最近はもっぱらパートナー会社様とのデータ連携環境構築を主に、時々プロダクションのMySQL環境と分析基盤との連携インフラの構築が多いです。 本記事は、メルカリに出品された過去すべての商品をBigQueryへ同期するにあたって取り組んだ時のお話です。 背景 当社では分析目的などでBigQueryを以前から使用しており、プロダクションのMySQLからBigQueryへデータを同期して分析に活用してきました。特に商品を表すテーブルは重要です。 しかし、後述する課題によりBigQueryにアップロードすることができなかったため、分析用のMySQLDBのスレーブとBigQueryを併用せざるを得ませんでした。とはいえ不便なので以前からBigQueryのみで商品テーブルも分析対象としたい要望がありました。 課題 メルカリでは販売済み商品を物理削除していないため、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
