階段探知Discをゲット

昨日ブログに書いて今日すぐにキタキタキタキタ━━━(゚∀゚≡(゚∀゚≡゚∀゚)≡゚∀゚)━━━━!!

f:id:forestkinoko:20181026144400j:plain

能力ディスクの構成も固まった。結構何消そうか迷った。
最終的に神父を消した。 f:id:forestkinoko:20181026164525p:plain

為替でここ2日で100万近く損失出しててもそんなの関係ない!
嬉しい!
ただこの瞬間を喜びたい!
100万!
クソッ!!!!
ドル円クソッ!!!!

ディアボロの大冒険ver0.15

ここ3ヶ月ぐらい、ずっとディアボロの大冒険ver0.15をプレイしていた。
大学生の時にそれこそ数えきれないほどver0.13をプレイしたが、5部のアニメも開始したので、 ver0.15を久しぶりにプレイ。

天国でずっと遊んでいるが、装備も大体固まった。

攻撃

f:id:forestkinoko:20181025083401p:plain

防御

f:id:forestkinoko:20181025085446p:plain

能力

f:id:forestkinoko:20181025085505p:plain

「階段の場所がわかるぞ」とか運よく手に入れたら組み込みたいが 出ないだろうなぁ。龍夢すらまだver0.15ではお目にかかってない。 (罠検知は☆ディスクから入手)

鉄獄も無周回クリアできた。 f:id:forestkinoko:20181025085732p:plain 承太郎に餌を与えてレベルを上げて、銛反射で大ダメージ!で勝利。

金エンブレムが周回クリア済みだとつかないらしい。残念。

Zabbixのアラート通知先をSlackにする

100番煎じ
Zabbixサーバーにログイン

# zabbix_server -V
Zabbix server v2.4.4 (revision 52341) (23 February 2015)
Compilation time: Feb 24 2015 20:50:19

# grep AlertScriptsPath /etc/zabbix/zabbix_server.conf
### Option: AlertScriptsPath
# AlertScriptsPath=${datadir}/zabbix/alertscripts
AlertScriptsPath=/usr/lib/zabbix/alertscripts

# cd /usr/lib/zabbix/alertscripts
# wget https://raw.githubusercontent.com/ericoc/zabbix-slack-alertscript/master/slack.sh
# ll | grep slac
-rw-r--r--. 1 root root 1580 10月 19 10:09 2018 slack.sh
# chmod a+x slack.sh
# ll -l slack.sh
-rwxr-xr-x. 1 root root 1580 10月 19 10:09 2018 slack.sh

SlackのWebhookURLの用意

https://hooks.slack.com/services/*****/*******

slack.shを修正する。

# Slack incoming web-hook URL and user name
url='CHANGEME'          # example: https://hooks.slack.com/services/QW3R7Y/D34DC0D3/BCADFGabcDEF123
username='ZabbixMan'

Zabbixで新規メディアタイプを作成する

設定 設定値
Name Slack
Type Script
Script Name slack.sh

Slackというエイリアス名でユーザー作成し、メディアは以下のように設定する f:id:forestkinoko:20181019111743p:plain

AlertTest

bash slack.sh '@hoge_taro' PROBLEM 'Oh no no no no '

ユーザー名を指定した場合はslackbotから以下のように届く
f:id:forestkinoko:20181019111806p:plain

あとはアクションの実行先で追加したメディアを指定すればOK

2018年半年終わって取引感想

2018年上半期は主にドル円WTI原油CFDに絞って取引した。
2018年3月頃に104円台でのLを幸運にも拾い、ピラミッド建設で
中々の利益を出すことができた。
原油は、基本的には長期は持たないで短期決済で回転していくのが上手く当たった。
ドル円原油ともに良い成績だった。
季節は早めに梅雨を終え、いよいよ夏の真っただ中に突入する中で、W杯が終わりを迎え、ドル円も112円まで上昇した。
少し新しい展開があるのかな、と思っている。
最近気になっていることは、アメの長期金利が3%を超えられないこと。うーん。 まあ兎に角、春先から持っていた大きなポジションを解消したので、これからどう動くかを見る時期か。
原油はちょっと読めないが、75ドルはもう中間選挙まで超えられないだろうという気はするので、 レンジを意識しつつ大きいポジションで買いを狙うのは年後半あたりからな感じ。
ドル円は様子見つつ、適度に参加していきたい 。

Azure AppService上のサイトへのリバースプロキシで苦しんだ話

以下の構成でサービスを運用している。

クライアント - リバースプロキシ(nginx) - Cloudservices

バックエンドをCloudServices → Azure App Serviceに置き換え、以下のように構成しようとした。

クライアント - リバースプロキシ(nginx) - Azure App Service

CloudServicesと異なる点は、AppServiceでは単一IPで複数のWebサイトをホストしていることだ。 (しようとしている )

IP固定も可能だけど。
AppService plan料金
Isolatedで、月3万円ぐらいかな。

クライアントからのリクエストURLはリバースプロキシのURLで変わらないので、リバプロで AppServiceの各サイトへの振り分けを行ってあげる必要がある。

Azure App Service の リージョンとスタンプ、IP アドレスについて

Azure App Service ではサイト固有の一意のパブリック IP アドレスは割り当てられていません。 したがって、Azure App Service では、IP アドレスや TCP ポートに一意性はないため、ホストヘッダー (サイト名、または、カスタム ドメインを構成している場合はドメイン名) を使用して HTTP 要求のルーティングをする必要があります。

と書いてあるように、ホストヘッダを指定して振り分けるしかなさそうである。

nginx的にはこんな感じ。

server {
    listen 443 ssl;
    server_name testproxy.com;

    location  /a {
        proxy_pass https://XXXXXXXXXX(AppServiceのIP)
        proxy_set_header Host  test1.com;
        proxy_redirect default;
    }
    location  /b {
        proxy_pass https://XXXXXXXXXX
        proxy_set_header Host  test2.com;
        proxy_redirect default;
    }
}

これで、リクエストはAppServiceに転送できるが、問題はバックエンド(AppService上のtest1.com、test2,com)で Hostヘッダを見てなんかやっている処理があったりする場合。

HTTP 1.1のHost:ヘッダーの保持

にも書かれているが、通常リバプロでは proxy_set_header Host $host; とか設定して、クライアントから渡された、あるいは設定されていなければserver_nameから取得した値を Hostヘッダに指定する。と思う。

今回はHostヘッダを(強引に)指定してプロキシしているために、バックエンドで問題が起こる可能性がある。(リダイレクト時など)

リクエストURLを取得する(ASP.NET プログラミング)

↑とか。Request.Urlプロパティから値を取得するのだが、内容はHostヘッダから組み立てている模様。

Application Request Routing (ARR) を使う場合に必ず設定しておきたい項目

アプリケーション側で Host ヘッダを見て URL を組み立てる場合に、プライベート IP アドレスがホストになってしまうことがあります。特に ASP.NET の Request.Url でこの問題が発生します

上記のようなことである。

  • バックエンドのアプリのHostヘッダを見てる処理に手を入れる
  • AppServiceプランをIsolatedにしてIP固定にする。(どうやら、Isolatedプラン以外では例え1サイトのみの構成にしてもHOSTヘッダは指定する必要がある)

結局、この2点の何れかにすることになった。 nginxで色々頑張る(リクエスト見ていろいろ書き換える)も検討したが、それはなんかちゃう、という気がしたのでやめた。

しかし、こういう用途(リバプロ + 単一IPで複数ホスト)ってほとんどWeb上の情報がでてこない。

詳しくないのでわからないが、この用途自体がおかしい(珍しい)のか……
サポートに聞いたらnginxでの構築事例は聞かないが、普通にAppService上にプロキシ立てて、そこから AppServiceに。みたいなのはあるらしい。
というかパスで振り分けるだけだったらApplicationGateway使えばええやね…… Azure Application Gateway の概要 | Microsoft Docs

nginxは時々触るが毎回苦しめられるので、記憶に定着するように形として残していきたいものである。

参考URLまとめ

HTTP のリダイレクション
リバースプロキシーと HTTP リダイレクト
ホストヘッダー
AzureWebAppsのSSLでドハマリ
Application Gateway の複数サイトのホスト
HTTP 1.1のHost:ヘッダーの保持
リダイレクト

AmaWeb設計&開発ガイド第一章

AmazonWebServices設計&開発ガイドを読み始めた。
第1章から。
AWSのメリットや、オンプレミスに対しての優位性についての説明。
パトリオット法が失効していたのは知らなかった。
セキュリティ的には、もちろんそれなりの自社サーバールームよりAmazon様のデータセンターのほうが万全のセキュリティで安全だというのは耳タコな話ではあるけれど、責任共有モデル(OSより上のレイヤーは利用者が責任をもって管理する)で、
自分としては何回かやらかしているので、安全か、といわれるとうーんとなる。(まあ、自分が悪いんですが。オンプレでは起きないようなことも逆に起こる)
クラウドを使うことに抵抗なくなってくると、複数クラウドからのサービス選択が
今後のスキルになっていく気がする。
Azureは何だかコンソールが好きじゃない。
ということで、そろそろAWS Solution Architecht Professional を取得したいので、朝早く起きて勉強したいと思う。
難しいのは勉強じゃなくて、朝起きることだが……