Azure リソース編集方法の使い分けと Azure Resource Explorer が便利だという話

MicrosoftAzure

AzureResourceExplorer をときどき使っていて便利だと感じているのでそれについて書く。
Azure をある程度使ってるがまださほど詳しくない、という人には参考になる部分がありそう。

Azure リソース編集方法の使い分け

Azure のリソースを編集する方法は、大きく3つだ。
スクリプト(azure-cli, PowerShell)、Azure ポータル、それから今回の AzureResourceExplorer である。
(他にも ARM Templete や REST API などもあるが割愛)

それぞれ特徴を上げる。

azure-cli, PowerShell

  • 新しいサービスリリース時の対応が早い
  • 特に azure-cli を使ったサンプルをよく見かける
  • Azure Cloud Shell の存在も相まって使い勝手がよい
  • スクリプトの流用しやすい

Azure ポータル

AzureResourceExplorer

  • 一部リソースの編集がしやすい
  • Azure の概念を理解しやすい
  • ARM Templete を書きたいときに参考になる
  • イチから作成するには不向き

このあと解説する。

便利なシーン

Network Security Group(NSG) のルールを一気に変更するときに便利

NSG のルールを編集しようとすると、azure-cli でも Azure ポータルでも一つずつしか変更ができず、毎回更新が入ってしまい、複数のルールをまとめて登録したいときに時間がかかる。
NSG のルール数は 上限が規定で200 なのでそこまで多くのルールを登録することはないかもしれないが、場合によってはあるだろう。
そういったときに JSON ベースで編集ができる Azure Resource Explorer ならば一気に複数ルールを編集し、更新することができる。
間違って設定したルールをまとめて削除するのも簡単だ。
これは非常に便利。

Azure の概念を理解しやすい

Azure ではまずリソースを購入するために必要なサブスクリプションや、AWS など他のクラウドにない概念としてリソースグループという概念がある。

f:id:khei-fuji:20171121235827p:plain

上の図のように、サブスクリプション、リソースグループ、リソースの種類に応じた namespace、リソース名、といった格好だ。
Azure のリソースはこれらの組み合せで URL がつくようになっている。 この URL を Get すればそのリソースの構成情報が JSON で取得できる、というシンプルなものだ。

これがわかると、リソースグループをまたげば同名のリソースを作れることや、サブスクリプション・リソースグループ・リソースの各階層でアクセス権限が設定できることがしっくりくる。

ARM Templete を書きたいときに参考になる

Azure には ARM Templete という、JSON で書いたファイルを使ってリソース群をまとめてデプロイする方法がある。
どんな風に書けば作れるかは azure-quick-templates を覗き見するのが早いだろう。
これを使って GitHub 上に Deploy To Azure ボタンをつけることもできる。

Deploy To Azure ボタンについてはこのあたりが詳しい。

ARM Templete を書くのは面倒なのだが、正しい状況を作ってから Azure Resource Explorer で JSON を確認しつつ編集すると捗る。

最後に

ということで AzureResourceExplorer の紹介おわり。


Azureテクノロジ入門 2018

Azureテクノロジ入門 2018

5年前にクラウド選定で考えてたこととか

雑記

思い出を書いていく。

当時の勤務先では Windowsアプリの開発(C#)が中心で、Web は片手間にやっていけそうなメンバがやる流れだった。
そのため Web のスキルは潰しが利く LAMP 一択。

自分は Web をやっていくメンバのをリードするポジションだったため、今後クラウドをやっていくのにどのクラウドを使うか選定することになった。
昨今の CTO がもてはやされるように、エンジニアが前面に出てものごとを決定していく風潮がなかったこともあり、あくまでも自分は「提案する立場」で決定するのはあくまでも役員（ただしエンジニアはいない）だった。

選定の土俵に上げたのは以下のクラウド。

今でこそ3強だが、当時はそこまで強くはなかったので、運営企業の大きさで選んだ覚えがある。 国産クラウドは調べてもよくわからず目に入ってこなかった。単にミーハーだったのかも。

当時役員等への提案で話したそれぞれの特徴はこんなところ。

Azure

  • C# 使えるし、スキル考えるとほぼこれ一択
  • 金額は3強どれも変わらない

AWS

  • PaaS がないのでインフラエンジニアがいない会社では厳しい

GCP

dotCloud

  • LAMP 使える
  • 金額が3強の半額以下
  • 運営企業に対しての不安材料

以上のことから Azure 8: dotCloud 2 くらいに思っていた。
コスト感によっては dotCloud になるだろう、と。

最近はもう聴かなくなったけど、クラウドがバズワードだった頃「IaaS, PaaS, SaaS」の3層の話をしたがるのは何だろうと思ってたが、非エンジニアに対してはさすがにこの説明が必要だった。しかし理解してもらえていたかはよくわからない。技術的な質問はなかったし、たぶん半数以上はわかってなかった。

結果、Azure を採用。
CloudService で苦しんで Web App に乗り換えるなど通るべき道を通ってきた。

今こうして振り返ってみると、金額だけ見て dotCloud 選ばなくて本当よかった。
Azure は Windows 系開発者にとって着実に進歩しているという意味でアテは当たったし、何より真っ当な判断がされたことがよかった。

しかしシェア以上にこれほど AWS の情報があふれる時代になるとは思わなかった。
Azure を選ぶ人たちの属性(情報を公開したがらない)にもよるのだけれども。

そして今年から立場が変わり、Azure を中心に扱う人となった。
正直クラウドはどれを選んでも2-3ヶ月である程度キャッチアップして使えるので、どれか一つを使って嫌だったらスイッチすればいいのかなと思う。
スマホのように「クラウド移行したい！」と言えばそのクラウドや周辺の人が喜んで知恵を貸してくれるし。
半期に一回くらいMSの営業らしき人から連絡が来ててウザいなあと思ってたけど、コストを浮かす方法ないか、とかいろいろ聞いておいたほうがよかったなあと今では思う。ライセンスやまとめ払いなど買い方による違いなんて全然情報入ってこないし、コミュニケーションコスト投じないと得られないとは想像つかなかった。現場のエンジニアがWebに書かない(書けない)話なので、外部から情報を取るようにしないとダメだったなあ、と。

ということでさりげなく弊社に相談してもらおうとするステマ込みな古い話でした。
ホント dotCloud 選ばなくてよかったよかった。

プログラマのためのDocker教科書 インフラの基礎知識&コードによる環境構築の自動化

プログラマのためのDocker教科書 インフラの基礎知識&コードによる環境構築の自動化

集中できる環境づくり

雑記

まえがき

ギョームの中で「ここぞ」ってときだったり、週末にやらないといけない作業があるときにどういう環境でやるかが結構大事だと感じてる。
人によって全然違うと思うが試しながらたどり着いた今の環境について書く。

ながら作業

ながらしない

まあまあ。
この状況が普段の生産性という扱い。
環境音に依存することになり、カフェやコワーキングスペースなどでは場所次第で集中が妨げられる。

動画視聴

悪い、基本的に避けるべき。
Netflix や Hulu(は解約したんだっけ), dアニメストア などを契約していたので動画を流しながら作業していたときがあったが、基本的に集中力の7割以上を持っていかれる。
同じ時間を使っても他と比べて圧倒的に生産性が低くなる。

取り組むのが億劫な作業に取り掛かるときの導入や、PCのセットアップなど待ち時間が多いときでのみ有効。　

音楽視聴

最高。
初見よりも聞き慣れたお気に入りの音楽があるのがよい。
作業用のプレイリストだったり、本筋ではないがランニング用のプレイリストなど、音楽がかかるとこれからやることにフォーカスできる印象がある。
ただしギョームで使うと周囲との協調がしづらくなる。
また1日のMP(集中できる時間)に限りがあるのでフルに使うのは避けている。

スプラトゥーンの合間

最悪。
5分に30秒くらいしか作業できない。

場所

職場

かなりよい。
やはりリーマンとしてスイッチが入るようになってるんじゃないか。
週末にいたくはない。

自宅

あまりよくない。
ベッドだったりゲームだったり誘惑が多いのが問題。
スイッチが入りさえすれば問題なくなる。

コワーキングスペース

場所によるがかなりよい。
お財布との兼ね合いになる。

たぶん安いところは椅子がよくない。
椅子は大事。
蒸れないこととお尻が痛くならないことなど。

コメダ珈琲

かなりよい。
コーヒーチケットを常備している。
混む時間帯はほどほどに。
食事込みで2000円程度で2-3時間作業できるのは魅力的。

LODGE

1回だけ行ったが、キレイだし整っていてよかった。
ただし週末は混んでいるのを覚悟しなければならなく、自分の場合は少し遠いので普段使いとしては微妙。

あとがき

結論として、音楽と椅子が大事ということになった。
自宅環境ももう少し整えたい。

ヘッドホンに数万円かける人が理解できずにいたけど、生産性高まるなら結果的に時間を買うことになるしアリなのかもしれない。

安くてもよいヘッドホンとしてコレ使ってたけど、もう少し出して買うかな。

PHILIPS ヘッドホン インイヤーカナル式 ホワイト SHE9711

PHILIPS ヘッドホン インイヤーカナル式 ホワイト SHE9711

ランニング用も欲しい。

The DevOps　逆転だ！究極の継続的デリバリー を読んだ

本

今週のお題「読書の秋」

久々に小説を読んだ。
そしてブログのお題も読書と来たので書く。
最近読んでヒットした本はこちら。

The DevOps　逆転だ！究極の継続的デリバリー

The DevOps　逆転だ！究極の継続的デリバリー


序盤はさほどではなかったが、中盤に入るあたりから続きが気になって睡眠時間を削りながら読むハメになった。

Amazon のあらすじに書かれているとおり、デスマーチプロジェクトが存在する。
そのデスマーチたる所以がありありと書かれており、わかるわかるとつい読み進めてしまった。

DevOps がなぜ必要なのかという基本知識2割、エンターテイメント8割といった印象。
日本のIT企業とは違った印象を抱く場面もあり、そのあたりは欧米の企業との差なのかと思った。


イカへの情熱が少し落ち着いてきたので、少しばかり生産的な活動にシフトしていきたい。

チャットサービスの機能を気軽に試しづらい

はてブに書くには長くなりそうなのでここに書く。

現在はシゴトで Slack やチャットワークなどを使っていて、やはり問題に感じるのが ツールに集中を妨げられること だ。
あえて反応しないというプラクティスを取り入れることでどうにかしようとしている。

そんな中で最近見かけたこの記事。

www.publickey1.jp

中でも気になったのは Focus Mode。

Strideには、一時的にコミュニケーションから離れて目の前の作業に集中できるように「Focus Mode」が用意されています。 ワンクリックで「Focus Mode」を設定すると、Strideのメッセージや通知はすべて停止されます。また、メンバーにも本人が集中作業中であることが分かるようになっています。 そしてFocus Modeを解除すると、Fucus Modeを設定中に発信された重要なメッセージなどをまとめて表示してくれます。

これすごくよさそう！と思った反面、手触り感を知りたいと思ったときにどうやって体験すればいいかで挫折した。
一人でアカウント作って試すとかでは全然ダメで、民族大移動した状態でないと全然良さがわからないではないかと。

たぶんそのうち動画が上がって使用感わかるようになるんだろうけど、すぐに忘れて、易きに流れるんだろうな。

スプラトゥーン2所感

雑記 買った物

思いがけず Switch が手に入った幸運で、スプラトゥーン2を買った。
プレイアブルになって24時間が経過する頃なので、所感。
ちなみに前回は発売半年後の WiiU + ソフトのセット割引に引かれて購入し、半年ほどプレイしていた。
最後のウデマエはS止まり。

ブログ書く時間が5分毎に1分くらいしかないので気になったことだけ書く。

スペシャル全般

全体としては弱体化している。
とはいえ前作が強すぎた印象。特にスーパーショット。
たぶん今後調整入ると思う。
今のところマルチミサイルが強い。

サーモン・ラン

サーモンラン | スプラトゥーン2 | Nintendo Switch | 任天堂

2からの追加要素。
これまではプレイヤー4人対プレイヤー4人のナワバリバトルorガチマッチだったが、このモードはプレイヤー4人対CPU(サーモン) というモード。

このモードではブキを任意で選べなくなっており、4種類用意されているブキ(シューター、二丁拳銃、チャージャー、ローラー)が4人にランダムに割り当てられる。
これは普段対戦で得意なブキばかり使いがちだった自分には普段使わないブキが割り当たることで幅が出てとてもいい。
前作では主にシューター系とホットブラスターを使ってたが、チャージャー系が楽しくなってきた。
主にガチヤグラでダンスをするチャージャー使いとして頑張っている。
こういう効果を狙ってるんだと思う。
ニガテなブキを使ってうまくいかなくても、対戦のスコア（ウデマエ）に影響しないし、ちょうどいい。

ガチホコ

これまでとホコを持ったときのブキが変わったことで大きく戦略が変わったと感じる。 これまではキルを狙うにはホコを持たないのがセオリーだったが、ホコのブキが非常に強力になったため、同人数同士の戦況だと攻撃側が有利になる。
守備側は時間をかければかけるほど不利になる。
なので人数揃ってるときに引いて守るのやめてもらいたい。

ブランク

前作やってからのブランクか、C帯で苦戦する。
よくよく考えると前回は発売半年後だったので本当のC帯と当たってたが、今は本来C帯じゃない人がたくさんいるので格差を感じやすいのかもしれない。
どっちにしろ、つらい。

最後に

知り合いの方はぜひ対戦しましょう。

Splatoon2 (スプラトゥーン2)|オンラインコード版

Splatoon2 (スプラトゥーン2)|オンラインコード版

Azure Database for MySQL を使いたかったので証明書の検証エラーを回避した話

PHP MicrosoftAzure

昨日しばやん先生の記事を見かけてました。 まさに使おうとしていたところで、他人ごとではありませんでした。

blog.shibayan.jp


公式情報

まずは公式情報。

現在、サービスへの mysql.exe 接続で “–ssl-mode=VERIFY_IDENTITY” オプションを使用した場合に、接続が次のエラーで失敗するという既知の問題が確認されています: ERROR 2026 (HY000): SSL connection error: SSL certificate validation failure Please downgrade to “–ssl-mode=VERIFY_CA” or lesser SSL modes (エラー 2026 (HY000): SSL 接続エラー: SSL 証明書の検証エラー “–ssl-mode=VERIFY_CA” または以前の SSL モードにダウングレードしてください)。 “–ssl-mode=VERIFY_IDENTITY” の使用が必要な場合は、サーバー名に ping を実行して、リージョン サーバー名を解決し (westeurope1-a.control.database.windows.net など)、この問題が解決するまで、接続内でそのリージョン サーバー名を使用します。 この制限は、今後削除する予定です。 Azure Database for MySQL に安全に接続するためにアプリケーションで SSL 接続を構成する | Microsoft Docs

ということなのでそのうち修正されるとは思いますが、現時点で使いたかったため、検証エラーを回避することにしました。


PHP はそれほど詳しくないため、以下の接続ドライバしか確認していません。

回避策

mysqli

mysqli_real_connect(
    $connection,
    $host,
    $user,
    $pass,
    $name,
    3306,
    '',
    MYSQLI_CLIENT_SSL_DONT_VERIFY_SERVER_CERT
);

参考: http://blog.machek.co.uk/2016/06/php-with-mysql-and-ssl.html

PDO

まだ対応できません。 PullReq 中のようです。

add a attribute to specify CN in PDO(version 7) by ghfjdksl · Pull Request #1913 · php/php-src · GitHub

おわりに

アップデートされたらこの記事の価値はなくなるので、そのころに見かけた人はスルーしてください。