はてなブックマーク

環境構築: VS Code Remote Container で Azure + Terraform + GitHub ActionsAzureDockerTerraformVSCodeGitHubActions Intro Fork して clone したらすぐに Azure を Terraform できる devcontainer を作りました。 VS Code の Remote Development (Remote - Containers) 機能を使っているので、ローカルに VS Code と Docker Desktop の環境があれば、以下のようなことがほんの少しの準備で実行できます。 Terraform で Azure を管理する terraform や Azure CLI az コマンドがすでに Docker コンテナ上のインストールされています。 GitHub Acti

Intro Azure Functions では、function.json にトリガーやバインディングなどの設定がされているが、数十といったレベルで多くの関数を作成したときに、この設定内容を一覧で確認したいことがある。function 名の一覧ならば、ソースコード上のディレクトリ名や Azure Portal 上で簡単に取得できるが、function.json の中身となると一つずつ開いて確認するのは効率が悪いので、find、xargs、jq などのコマンドラインで解決する。 Azure Cloud Shell でもよいし、Windows マシンでも WSL でこのあたりのコマンドラインがさらっと利用できるので、手軽に確認できる。 How 状況はこんな感じでたくさんの関数を作ったとする。 $ ls * host.json local.settings.json requirements.

Intro 今年 2020 の Microsoft Build はオンライン開催となりました。（アナウンス） https://mybuild.microsoft.com/ ということで、参加費用は無料です。登録は ページの Register Now リンクから です。 海外イベントを日本から視聴するときに毎度最初にやる作業は日本時間の確認なのですが、全セッションにちまちま追記しました。せっかくなので使ってください。 今回はタイムゾーンの配慮なのか、時間をずらしてくれてそうなのと、タイトルが同じ（おそらくリピートセッション）ものがあるので都合のいい枠を選んで参加できそうです。 2020/05/15 追記 以下のとおり、全てのセッションカタログが公開されました。イベント登録後は Session Scheduler でセッションを一覧できて、ここでセッション時刻を JST で確認できます。登録後

Intro 目的 Azure Monitor で発生するログの待ち時間を理解して、どこで待ち時間が発生しているか収集されたログを調べてみましょう。 結論 Azure Monitorに収集されるログレコードには、標準で、ログ生成時刻 TimeGenerated、インデックス完了時刻 ingestion_time() が記録されているので、これらの差分を見るとどれだけ待ち時間があったかわかります。 仕組みの理解 Azure Monitor は、Azure の共通基盤として提供されているログデータサービスです。 待ち時間 latency について 集めているはずのログをクエリしても結果に出てこない！となることがありますが、これは、ログが収集されてからクエリできるようになるまでにいくつか必要なプロセスがあり、それぞれに待ち時間が発生するためです。 以下の図を見てください。 ログ収集エージェント そ

Intro コンテナ向けに用意されている Azure Monitor for Containers では、最初から以下4つの Workbooks が提供されている。 ディスク容量 ディスクIO Kubelet ネットワーク この記事では、これらの既に出来上がっている Workbooks から、Kustoクエリをひたすら参考にしていきたい。このデフォルトの Workbooks はいつでもどのクラスターでも参照できるので、チートシート的に使うととても便利である。以下に紹介する kusto クエリを隅々まで覚える必要は全くない。 Azure Monitor Workbooksとは ログクエリ結果やグラフを複数まとめてレポート形式にできるもの。作成したレポートはチーム内で共有できるので、新メンバーがログのクエリ方法がわからない！という場合でも、「ああこのテレメトリを見れば○○がわかるのか」といった

Microsoft Azure Tech Advent Calendar 2019 の21日目です。 Intro パイプラインを実現する様々な GitHub Actions の開発がオープンソースで進んでいますが、利用するだけでなく独自の Actions を作成することができます。 GitHub アクションでワークフローを自動化する アクションのビルド この記事では、まずは Azure Functions を GitHub Actions でデプロイしたうえで、パイプラインの動きをログで確認しながら、Actions のソースコードを見ていきたいと思います。 Azure Functions を GitHub Actions でデプロイする 正式な手順やドキュメントは以下に情報があります。 Docs: Continuous delivery by using GitHub Action htt

はじめに この記事で説明する/しないこと kong 自体の説明は割愛したい。API Gateway のソフトウェア。 Hosted なサービスである、Mashape というサービスが、 そのプラットフォームである Kong をオープンソース化した。 kong の代替はこのあたり。 Apigee、Tyk、KrakenD あたりとのこと。 なぜ API Gateway か、についても割愛したい。すでに多くは API Gateway Pattern などで言及されている。 大事：kong は client から接続用と admin から接続用で二つポートが必要なのだが、Azure Web App for Containers はポートを一つしか公開できない制約があるため、Web App をそれぞれようにデプロイする。以下のような具合。 client 接続用 kong.azurewebsite.n

この記事について この記事は、Things You Should Know: Web Apps and Linux という記事を要約＆意訳したもの。 App Service on Linux / Web App for Containers について、使い始めてチュートリアルを終えたあたりから気になってくるポイントがまとまっている。 元記事のヘッダ見出しごとになるべく短め（省略含む）に書いているため、内容詳細はぜひ元記事を参照いただきたい。 本文 Azure App Service on Linux は、Microsoft が提供するランタイムスタック一式でWeb App を利用できる。 Web App for Containers は、Azure Container Registry や Docker Hub、またはプライベートなレジストリ上の独自のDockerコンテナを利用することがで

IntelliJに手が馴染んでくると、いつも使うテキストエディタとしても使いたくなってくる。 そのユースケースで必要な設定やキーマップ（ショートカット）などをまとめてみた。 個人的な要望としては、JetBrains社にプログラミング機能を除いたコアな部分をシンプルなエディタとして提供してほしい。 前提 通常のエディタに比べて決して軽いソフトではないが、昨今のマシンであれば気にならない範囲だと思う。 とはいえ、もちろん最初の起動はそれなりに遅い。よっぽどでないと使い続けるには至らないと思われる。 一ヶ月ほど使い続けてみて書き溜めてみた。まだあるはずなので、適当に更新したい。 フォントなど外観の話はそれぞれの好みだと思うのでここでは触れない。 基本デフォルト設定で。 ショートカット操作などは、Macのものしか書いていない。ごめんなさい。 Version IntelliJ IDEA 14.1.4

➜ ~ brew install homebrew/versions/maven31 Cloning into '/usr/local/Library/Taps/homebrew/homebrew-versions'... remote: Counting objects: 2770, done. remote: Total 2770 (delta 0), reused 0 (delta 0) Receiving objects: 100% (2770/2770), 909.49 KiB | 141.00 KiB/s, done. Resolving deltas: 100% (1621/1621), done. Checking connectivity... done. Tapped 171 formulae ==> Installing maven31 from homebrew/h