この記事は、NEXTSCAPE Advent Calendar 2021 の 1 日目 の記事です。 qiita.com 先日の Microsoft Ignite で発表された Azure Container Apps で、Reverse Proxy に YARP を使ってみました。 ショッピングサイトのマイクロサービスを想定して、Item Service、Pos Service、Stock Service を API Gateway パターンで公開するシナリオで試したいと思います。 Azure Container Apps における Reverse Proxy の必要性 Azure Container Apps は、サーバーレスなプラットフォームであり、複数のコンテナアプリケーションで構成されるマイクロサービスの構築を支援するサービスです。 HTTP エンドポイントを公開するすべてのマイ
かれこれ 5 年くらい趣味開発で npm-scripts を書き続けている。長年書き続けているとノウハウが蓄積されてきて、「こう書くとスッキリする」「迷いがなくなる」「後から拡張したくなった時に、簡単に拡張できる」みたいな書き方が身についてきた。自分の型、あるいは手癖のようなものだと思う。 せっかくなので、id:mizdra の今の npm-scripts を書く時の手癖を書き連ねてみる。 基本形 { "scripts": { "build": "webpack --mode production", "dev": "webpack-dev-server --mode development", "lint": "eslint .", "test": "jest" } } 一番シンプルな npm-scripts を書く時のパターン。以下の 4 つの script を登録している。 buil
SASL とはSimple Authentication and Security Layer の略です。RFC4422 で定められています。 Web (http) やメール (SMTP, POP3, IMAP) 等では認証が必要になるケースが多いですが、アプリケーション開発者が毎回わざわざ認証モジュールを 1 から作るのはナンセンスです。 SASL は認証 (Authentication) のやり取りと認証情報の保護 (Security) に関する仕組みをあらかじめアプリケーションが使いやすいようにプラグインとして用意しているフレームワークです。 これにより、アプリケーション開発者は認証に関する開発は行わなくて済みます。 SASL を通して以下の 3 つのセキュリティ機能を提供します。 通信相手が正しいこと (認証: Authentication)通信が改竄されていないこと (完全性:
シングルサインオン(SSO)とは一般的なシステムでは、各サーバ毎にユーザ ID とパスワードを各サーバが持っています。 AD 連携、LDAP 連携や、さらにそれを束ねる統合 ID 管理ソリューションによって、ID / パスワードを共通化することもできますが、この場合でも各サーバそれぞれに対してログインプロセスが必要になります。 シングルサインオン環境を構築すると、通常は各々で認証が必要な複数システム (サーバ) に、1 つ認証したら他の全てのシステムでは認証プロセス無しにログインできるようになります。 Windows の SSO (ActiveDirectory)企業内システムで一番身近な SSO は ActiveDirectory です。 ドメイン参加した Windows 端末にて、ActiveDirectory に登録されたドメインユーザでログインすると、Kerberos というプロト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
