After a long time, I am.

日々のメモ

ディアボロの大冒険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 を取得したいので、朝早く起きて勉強したいと思う。
難しいのは勉強じゃなくて、朝起きることだが……

fifa18キャリアモード

目標とか色々たてなきゃなーとか思ってた新年だけどここまでfifa18 switch版をやっているばかりで何にも考えてない 目標とか考えるのは苦痛。特に自発的でないときは。
目標とかキャリアプランとか怠い。

レジェンドレベルのfifaは難しい。
ニューカッスルでの成績
1年目:38試合10勝8分20敗 26得点51失点 16位
2年目:27試合8勝11分8敗 31得点35失点10位
途中解任された……ショックすぎる

エニアグラム簡易診断とかいうのやったら 「平和を好む人」だった。

エニアグラム 〜9つのタイプ 性格の特徴、世界観、動機、行動スタイル、エッセンス(本質的資質)

穏やかで、人に安心感を与え、気持ちをなごませる。人から見捨てられることを恐れ、平和や快適であること、また、一体感を好む。健全な状態で、平和で安定した心を保つ。周囲に緊張や葛藤がある場合は、公平な立場で辛抱強く仲裁に入る。想像力に富み、楽観的なヴィジョンをもつ。
性格のとらわれが強くなると、表面的にまわりに合わせ、葛藤を避け、実態よりもいい方に理想化して考えてしまう。頑固なまでに現状維持。自分は成長するに値しないと思いがちで、変化へ向けての積極的な行動を起こせない。怒りや不満を直接表現せずに、暗黙の抵抗で示す。不健全なとき、まわりの人から気持ちが離れ、問題に直面することなく、自分を麻痺させて、心地良い空想や嗜癖、フテ寝などに走る。抑鬱や無感覚になる。

平和を好む人がfifa18のCOMエフェクトにキレてコントローラー投げ飛ばしたりするんだろうか…… 謎である。

読書計画(冬)

年末に向けて、読みたい本や持っている本の棚卸。

持っている本

UNIXという考え方

UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学

名言集。

サーバーレスシングルページアプリケーション

クラウドデザインパターン設計ガイド

Amazon Web Servicesクラウドデザインパターン設計ガイド 改訂版(日経BP Next ICT選書)

Amazon Web Servicesクラウドデザインパターン設計ガイド 改訂版(日経BP Next ICT選書)

シナリオで学ぶパブリッククラウド Amazon Web Services 設計&開発ガイド

シナリオで学ぶパブリッククラウドAmazon Web Services 設計&開発ガイド

シナリオで学ぶパブリッククラウドAmazon Web Services 設計&開発ガイド

TCP/IPネットワーク ステップアップラーニング

[改訂4版]TCP/IPネットワーク ステップアップラーニング

[改訂4版]TCP/IPネットワーク ステップアップラーニング

ネットワーク基礎の再確認。

みんなのPython

みんなのPython 第4版

みんなのPython 第4版

Pythonがやりたくてとりあえず買った。

持っていない本

アメリカ海軍に学ぶ「最強チーム」のつくり方

ちらっと読んだ時に書いてあった「人が辞める理由」がとてもしっくりきたので ちゃんと読んでみたい。 ちなみに、軍艦を降りる5つの理由(アメリカ海軍)

  1. 上司から大切に扱ってもらえないこと
  2. 積極的な行動を抑えこまれること
  3. 意見に耳を貸してもらえないこと
  4. 責任範囲を拡大してもらえないこと
  5. 給料

Amazon Web Services負荷試験入門

読みたい。負荷試験自体に知見が足りないと感じている。

SRE サイトリライアビリティエンジニアリング

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SREって最近よく聞く職なので。

Real World HTTP

Real World HTTP ―歴史とコードに学ぶインターネットとウェブ技術

Real World HTTP ―歴史とコードに学ぶインターネットとウェブ技術

Webを支える技術という本があるが、それに匹敵するぐらい良いらしい

Infrastructure as Code

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

あまり食指は動かないが、まあ。。

ピープルウェア

ピープルウエア 第3版

ピープルウエア 第3版

著者のデッドラインという作品が面白かったので。 こちらのほうが有名らしい。