Explain containerize design using WASM and Blazor, WASI WebAssemblyとBlazor 、 WebAssembly System Interfaceで コンテナライズの設計を解説
Profile システム構築のプロセス評価、改善、策定、 開発フレームワークの設計、実装管理、プリ セールスやプロジェクトの立ち上げなど ブログ : http://blog.processtune.com プロフィール : Facebook, Twitter or MVP コミュニティ : .NETラボの運営スタッフ Microsoft MVP : July 2010 ~ Jun 2022 Current expertise : MVP for Developer Technologies
Containerization 01 メッセージング・ミドルウェアは、分散コンピ ューティングのアーキテクチャの一部です。 実装の形としてgRPC、Kafka、SignalR、 Azure Web PubSubなどがあります。 WASM、WASI 02 Code 03 WSLのubuntuに配置したdockerイメージ 内のnodeに実装したWebアプリから、 RustのQRコード生成プログラムを含む WebAssemblyを配信し、エッジサイドで QRコードを生成、編集します。 Conclusion 04 本セッションのまとめ Link 05 Agenda PWA(Progressive Web Application)、 WebAssembly、 WebAssembly System Interface、 Blazorの仮想化技術 本セッションの作成における 出典と追加の技術情報
Containerization 01 メッセージング・ミドルウェアは、分散コンピ ューティングのアーキテクチャの一部です。 実装の形としてgRPC、Kafka、SignalR、 Azure Web PubSubなどがあります。 WASM、WASI 02 PWA(Progressive Web Application)、 WebAssembly、 WebAssembly System Interface、 Blazorの仮想化技術 Code 03 WSLのubuntuに配置したdockerイメージ 内のnodeに実装したWebアプリから、 RustのQRコード生成プログラムを含む WebAssemblyを配信し、エッジサイドで QRコードを生成、編集します。 Conclusion 04 本セッションのまとめ Link 05 本セッションの作成における 出典と追加の技術情報 Agenda
Containerization 01 メッセージング・ミドルウェアは、分散コンピ ューティングのアーキテクチャの一部です。 実装の形としてgRPC、Kafka、SignalR、 Azure Web PubSubなどがあります。 WASM、WASI 02 PWA(Progressive Web Application)、 WebAssembly、 WebAssembly System Interface、 Blazorの仮想化技術 Code 03 WSLのubuntuに配置したdockerイメージ 内のnodeに実装したWebアプリから、 RustのQRコード生成プログラムを含む WebAssemblyを配信し、エッジサイドで QRコードを生成、編集します。 Conclusion 04 本セッションのまとめ Link 05 本セッションの作成における 出典と追加の技術情報 Agenda
Containerization 01 コンテナ化とメッセージング・ミドルウェア、メッセージの方 向のパターンとコンテナライゼーションの範囲について
コンテナ化の範囲について Containerization マイクロサービスとコンテナ化のコンセプトはよく似ており、どち らもソフトウェア開発の手法として、アプリケーションをより小 さなサービスやコンポーネントの集合体に変換し、移植性、 拡張性、効率性、管理のしやすさを実現するものです。 さらに、マイクロサービスとコンテナ化は一緒に使うと効果的 です。コンテナは、従来のモノリス型やモジュラー型のマイクロ サービスに関わらず、あらゆるアプリケーションを軽量にカプセ ル化します。コンテナ内で開発されたマイクロサービスは、開 発プロセスの移植性、ベンダーとの互換性(ベンダーロック インなし)に加え、開発者の俊敏性、障害の隔離、サーバ ーの効率化、インストール、スケーリング、管理の自動化、セ キュリティの強化など、コンテナ化特有のメリットをすべて享 受することができます。
ステートフル・ミドルウェア 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 永続化層 永続化層
dockerの準備(ARM) curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg echo "deb [arch=arm64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null $ sudo apt-get install apt-transport-https ca-certificates curl gnupg lsb-release 初めてWSLを使う場合はツール群をインストール docker ce(community edition)がインストールされていない場合 GNU Privacy Guard (GnuPG, GPG)キーの取得と配置 $ sudo apt-get update $ sudo apt-get install docker-ce docker-ce-cli containerd.io $ apt-cache madison docker-ce インストールできるdocker ceの確認 $ sudo apt-get install docker-ce=5:20.10.8~3-0~ubuntu-focal docker-ce-cli=5:20.10.8~3-0~ubuntu-focal containerd.io docker ceのインストール
・runに引数「--rm」をつけると作 業終了後にコンテナを削除するこ とができます 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 永続化層 永続化層 Nginx $ sudo docker pull nginx $ sudo docker run -dit -p 8080:80 --init --name rproxy nginx $ sudo docker exec –it rproxy /bin/bash # apt-get install vim # vim /etc/nginx/nginx.conf conf $ sudo service docker start Dockerがスタートしてなかったら
開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 永続化層 永続化層 ステートフル・ミドルウェア $ sudo docker pull nginx $ sudo docker run -it -d -p 8080:80 –name rproxy nginx $ sudo docker exec –it rproxy /bin/bash # apt-get install vim # vim /etc/nginx/nginx.conf conf $ sudo service docker start Dockerがスタートしてなかったら
$ sudo docker pull node $ sudo docker run –dit –p 8081:3000 --init --name svgcoloringweb node $ sudo docker exec –it nodeweb /bin/bash # cd /home/node # apt update && apt upgrade -y # npm init # npm install –g express-generator # express # npm i --package-lock-only # npm audit fix --force # DEBUG=node:* npm start 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 永続化層 永続化層 Node root@6c857308d3b7:/home/node# DEBUG=node:* npm start > node@0.0.0 start > node ./bin/www node:server Listening on port 3000 +0ms ^C root@6c857308d3b7:/home/node# Expressの既定はポート3000なので、 これが出たらいったんCtrl+Cで終了しapp.jsを編集します pug(jade) = データドリブンなホームページ・テンプレート EJS =スタンダードなJavaScriptホームページ・テンプレート Handlebars = イベント定義を簡素化したホームページ・テンプレート Hogan.js = テンプレートの動的変更が可能 Twig = PHP用のホームページ・テンプレート ・途中は既定の まま「y」で進む ・脆弱性は0に なるまで修正
$ sudo docker pull node $ sudo docker run –it –d –p 8081:3000 –name svgcoloringweb node $ sudo docker exec –it nodeweb /bin/bash # cd /home/node # apt update && apt upgrade -y # npm init # npm install –g express-generator # express # npm i --package-lock-only # npm audit fix --force # DEBUG=node:* npm start 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 永続化層 永続化層 Node pug(jade) = データドリブンなホームページ・テンプレート EJS =スタンダードなJavaScriptホームページ・テンプレート Handlebars = イベント定義を簡素化したホームページ・テンプレート Hogan.js = テンプレートの動的変更が可能 Twig = PHP用のホームページ・テンプレート ・途中は既定の まま「y」で進む ・脆弱性は0に なるまで修正
$ sudo docker pull node $ sudo docker run –it –d –p 8081:3000 –name svgcoloringweb node $ sudo docker exec –it nodeweb /bin/bash # cd /home/node # apt update && apt upgrade -y # npm init # npm install –g express-generator # express # npm i --package-lock-only # npm audit fix --force # DEBUG=node:* npm start 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 永続化層 永続化層 Node pug(jade) = データドリブンなホームページ・テンプレート EJS =スタンダードなJavaScriptホームページ・テンプレート Handlebars = イベント定義を簡素化したホームページ・テンプレート Hogan.js = テンプレートの動的変更が可能 Twig = PHP用のホームページ・テンプレート ・途中は既定の まま「y」で進む ・脆弱性は0に なるまで修正
$ sudo docker pull node $ sudo docker run –it –d –p 8081:3000 –name svgcoloringweb node $ sudo docker exec –it nodeweb /bin/bash # cd /home/node # apt update && apt upgrade -y # npm init # npm install –g express-generator # express # npm i --package-lock-only # npm audit fix --force # DEBUG=node:* npm start 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 永続化層 永続化層 Node pug(jade) = データドリブンなホームページ・テンプレート EJS =スタンダードなJavaScriptホームページ・テンプレート Handlebars = イベント定義を簡素化したホームページ・テンプレート Hogan.js = テンプレートの動的変更が可能 Twig = PHP用のホームページ・テンプレート ・途中は既定の まま「y」で進む ・脆弱性は0に なるまで修正
$ sudo docker pull node $ sudo docker run –it –d –p 8081:3000 –name svgcoloringweb node $ sudo docker exec –it nodeweb /bin/bash # cd /home/node # apt update && apt upgrade -y # npm init # npm install –g express-generator # express # npm i --package-lock-only # npm audit fix --force # DEBUG=node:* npm start 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 永続化層 永続化層 Node pug(jade) = データドリブンなホームページ・テンプレート EJS =スタンダードなJavaScriptホームページ・テンプレート Handlebars = イベント定義を簡素化したホームページ・テンプレート Hogan.js = テンプレートの動的変更が可能 Twig = PHP用のホームページ・テンプレート ・途中は既定の まま「y」で進む ・脆弱性は0に なるまで修正
$ sudo docker pull node $ sudo docker run –it –d –p 8081:3000 –name svgcoloringweb node $ sudo docker exec –it nodeweb /bin/bash # cd /home/node # apt update && apt upgrade -y # npm init # npm install –g express-generator # express # npm i --package-lock-only # npm audit fix --force # DEBUG=node:* npm start 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 永続化層 永続化層 Node pug(jade) = データドリブンなホームページ・テンプレート EJS =スタンダードなJavaScriptホームページ・テンプレート Handlebars = イベント定義を簡素化したホームページ・テンプレート Hogan.js = テンプレートの動的変更が可能 Twig = PHP用のホームページ・テンプレート ・途中は既定の まま「y」で進む ・脆弱性は0に なるまで修正
$ sudo docker pull node $ sudo docker run –it –d –p 8081:3000 –name svgcoloringweb node $ sudo docker exec –it nodeweb /bin/bash # cd /home/node # apt update && apt upgrade -y # npm init # npm install –g express-generator # express # npm i --package-lock-only # npm audit fix --force # DEBUG=node:* npm start 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 永続化層 永続化層 Node pug(jade) = データドリブンなホームページ・テンプレート EJS =スタンダードなJavaScriptホームページ・テンプレート Handlebars = イベント定義を簡素化したホームページ・テンプレート Hogan.js = テンプレートの動的変更が可能 Twig = PHP用のホームページ・テンプレート ・途中は既定の まま「y」で進む ・脆弱性は0に なるまで修正
$ sudo docker pull node $ sudo docker run –it –d –p 8081:3000 –name svgcoloringweb node $ sudo docker exec –it nodeweb /bin/bash # cd /home/node # apt update && apt upgrade -y # npm init # npm install –g express-generator # express # npm i --package-lock-only # npm audit fix --force # DEBUG=node:* npm start 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 永続化層 永続化層 Node pug(jade) = データドリブンなホームページ・テンプレート EJS =スタンダードなJavaScriptホームページ・テンプレート Handlebars = イベント定義を簡素化したホームページ・テンプレート Hogan.js = テンプレートの動的変更が可能 Twig = PHP用のホームページ・テンプレート ・途中は既定の まま「y」で進む ・脆弱性は0に なるまで修正
-- current directory : /home/node # apt update && apt upgrade -y # apt install git # git config --global user.name ”tetsuro takao” # git config --global user.email ”tetsuro.takao@processtune.com” # git config --global init.defaultBranch main # apt update && apt upgrade -y # apt install vim # apt update && apt upgrade -y 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 永続化層 永続化層 git
-- current directory : /home/node # exit $ sudo docker commit svgcoloringweb svgcoloringweb:v0.1 $ sudo docker save svgcoloringweb:v0.1 > /mnt/c/users/%USER NAME%/user/globalstorage/svgcoloringweb.v0.1.tar 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 永続化層 永続化層 Save
開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 永続化層 永続化層 ログインユーザーのステート ユーザーに 紐づくステート
マイクロサービスの設計 https://domaindrivendesign.org/ コンテキスト を設計 ドメイン構成 を設計 モデル を作成
ドメイン・ドリブン・デザインの要素 ドメイン サブドメイン バウンデッド・コンテキスト エンティティ バリューオブジェクト サービス イベント バウンデッド・コンテキスト … … … … … サブドメイン バウンデッド・コンテキスト エンティティ コンテキスト固有の エンティティ インジェクションによ る亜種モデル … … ユーザー・インターフェイス アプリケーション クラウド・オンプレミス インフラストラクチャ
バウンデッド・コンテキスト QRコード情報 (ユースケース/バウンデッド・コンテキスト) ログインユーザー (バリュー・オブジェクト) SVG(エンティティ) 色(エンティティ) 履歴(エンティティ) ログイン情報 (ユースケース/バウンデッド・コンテキスト) ログインユーザー (バリュー・オブジェクト) ログイン状態(エンティティ) アイデンティティ・プロバイダー (バリュー・オブジェクト) フリーアイコン情報 (ユースケース/バウンデッド・コンテキスト) ログインユーザー (バリュー・オブジェクト) URL(エンティティ) 画像(エンティティ) 色(エンティティ) ログイン情報 (ユースケース/バウンデッド・コンテキスト) ログインユーザー (バリュー・オブジェクト) ログイン状態(エンティティ) アイデンティティ・プロバイダー (バリュー・オブジェクト) SVG色付けアプリ (ドメイン) QRコード生成機能 (サブドメイン/ユーザーストーリー) フリーアイコン色付け機能 (サブドメイン/ユーザーストーリー)
エンティティとバリューオブジェクト SVG(エンティティ) URL 画像 XML 色(エンティティ) RGB 名前 English ログインユーザー (バリュー・オブジェクト) ID 表示名 認証URL アイコンURL アイコン色 QRコード QRコード色 アイデンティティ・プロバイダー (バリュー・オブジェクト) ロゴ 認証URL アクセス・トークン リフレッシュ・トークン 発行者
サービスとイベント 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 永続化層 永続化層
サービスリポジトリとアグリゲート、ファクトリ Node (製品コンテナ) Alpine Linux ファクトリ ステートフル・ミドルウェア 永続化層 SVG アカウントに紐づくURLへ SVGを要求 アカウントで SVGを要求 アカウント SVGを保存 … … … … … アカウントから SVGを引く https://freesvg.org/ アイコンサービス のアイコン情報 … … ログインサービス のログインモデル サービスリポジトリ :そのサービスが扱うバウンデッドコンテキストのモデルの形で永続化する アグリゲート :他のバウンデッドコンテキストのモデルとそのサービスが扱うバウンデッド コンテキストのモデルの形に合致させるための翻訳を行う ファクトリ :サービスの入出力口 アグリゲート サービスリポジトリ モデルへ … … アイコンサービス のログインモデル SVGそのものか ら抜き出す SVG URL XML … … … … … アイコンサービス のアイコン情報 … … アイコンサービス の色モデル
イベント(イベントの明確化による機能要件の追加) Node (製品コンテナ) Alpine Linux ファクトリ ステートフル・ミドルウェア 永続化層 SVG アカウントに紐づくURLへ SVGを要求 SVG アカウントで SVGを要求 アカウント SVGを保存 アカウントから SVGを引く https://freesvg.org/ アグリゲート サービスリポジトリ SVGそのものか ら抜き出す 「ユーザー操作による最新情報の取得」、「常に最新の情報を取得し、取得できなかった場合に のみ永続化層のデータを使う」などの制約はマイクロサービスの可搬性、再利用性を失います。 そのため、サービスに最新の問合せを行うかどうかのオプションも設ける。
MongoDB + Node 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 永続化層 永続化層 mongoの既定はポート27017、expressの既定ポートは3000なので、 mongoはそのまま、expressのapp.jsを8082に編集します。 ./bin/wwwにも同じ記述がありますので修正します。 $ sudo docker pull mongo $ sudo docker run -d -p 8082:80 -p 27017:27017 --init --name svgfreeicondb mongo:latest $ sudo docker exec -it svgfreeicondb /bin/bash # apt install -y curl # curl -fsSL https://deb.nodesource.com/setup_17.x | bash # apt install -y nodejs # npm install -g npm # apt update && upgrade -y # mkdir /home/node # chmod 777 /home/node # cd /home/node --以下node同じ手順でexpressを実行しWebアプリを作成
ポートの修正 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 永続化層 永続化層 mongoの既定はポート27017、expressの既定ポートは3000なので、 mongoはそのまま、expressのapp.jsを80に編集します $ sudo docker pull mongo $ sudo docker run -d -p 8082:80 -p 27017:27017 --init --name svgfreeicondb mongo:latest $ sudo docker exec -it svgfreeicondb /bin/bash # apt install -y curl # curl -fsSL https://deb.nodesource.com/setup_17.x | bash # apt install -y nodejs # npm install -g npm # apt update && upgrade -y # mkdir /home/node # chmod 777 /home/node # cd /home/node --以下node同じ手順でexpressを実行しWebアプリを作成
MongoDBの確認 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 永続化層 永続化層 mongoの既定はポート27017、expressの既定ポートは3000なので、 mongoはそのまま、expressのapp.jsを80に編集します $ sudo docker pull mongo $ sudo docker run -d -p 8082:80 -p 27017:27017 --init --name svgfreeicondb mongo:latest $ sudo docker exec -it svgfreeicondb /bin/bash # apt install -y curl # curl -fsSL https://deb.nodesource.com/setup_17.x | bash # apt install -y nodejs # npm install -g npm # apt update && upgrade -y # mkdir /home/node # chmod 777 /home/node # cd /home/node --以下node同じ手順でexpressを実行しWebアプリを作成
MongoDB for VS Code Extension 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 永続化層 永続化層 mongoの既定はポート27017、expressの既定ポートは3000なので、 mongoはそのまま、expressのapp.jsを80に編集します
dotnet new --use-minimal-apis --no-https 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 MongoDB 永続化層
dotnet new --use-minimal-apis --no-https 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 MongoDB 永続化層
dotnet new --use-minimal-apis --no-https 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 MongoDB 永続化層
設定ファイルと設定値の読み込み 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 MongoDB 永続化層
Swagger 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 MongoDB 永続化層
メッセージング部 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 MongoDB 永続化層
SVG free icon list App 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 MongoDB 永続化層
GitHub CLIのインストール # curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | gpg --dearmor -o /usr/share/keyrings/githubcli-archive-keyring.gpg # echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main“ | tee /etc/apt/sources.list.d/github-cli.list > /dev/null カレントディレクトリ/home/node # touch .gitignore # vim .gitignore 以下追加(「i」) node_modules/ .* 終了(「esc」「:」「w」「ent」「:」「q」「ent」) Gitを初期化 # apt update && apt upgrade –y # apt install gh # apt update && apt upgrade –y GitHub CLIのインストール GNU Privacy Guard (GnuPG, GPG)キーの取得と配置 # vim app.js 以下追加(「i」) app.set(‘port’, process.env.PORT || 80); 終了(「esc」「:」「w」「ent」「:」「q」「ent」) # exit app.jsを変更してポート3000をポート80に変更 ポートを80に直 していない場合
GitHubへコミット # git init # git add . && git commit -m "initial commit" gh auth login --ここからCLIで作業(矢印キーで操作) ? GitHub.com ? HTTPS ? y ? Login with a web browser ! [Enter] …ブラウザで作業…[Enter] # gh repo create ? Push an existing local repository to GitHub ? [Enter](ピリオド「.」カレントディレクトリの選択) ? SVGFreeIconListingApp ? 説明は任意の文章を入れてください ? Public(今回はサンプルなので、通常の開発ではPrivateなどを選ぶ) ? y(リモートのリポジトリパスを確認) ? y(リモート名「origin」を確認) ? y(現在のブランチをリモートにコミットすることを確認) メインブランチを初期化して、ローカルを初回コミット後GitHubにログインしてCLIでリポジトリを作成
Windows側の設定 *SVGFreeIconListingApp> npm --version *SVGFreeIconListingApp> npm install *SVGFreeIconListingApp> npm install http-errors *SVGFreeIconListingApp> dotnet new .gitignore *SVGFreeIconListingApp> dotnet dev-certs https --trust *SVGFreeIconListingApp> npm i express body-parser *SVGFreeIconListingApp> npm start 1. nodeのバージョンを確認、Linuxで作成したnodeアプリのバージョンを公式インストーラーを 使ってインストール 2. .gitignoreでnode_modulesを抜いてあるので追加する。http-errorsも追加。 3. .gitignoreファイルも追加します。 4. このアプリはサービスなのでjsonを頻繁に使います。デバッグのためbody-parserと開発証 明書もインストールしておきます。 5. これをpushしてLinux側を上書きします。 6. コンテナの中で動いていたためポートは80です。https://localhost
Rust Teams Toolkit Deploy Teams apps with Microsoft Graph, and in Azure and M365 Azure Static Web Apps Create and manage Azure Static Web Apps directly Remote Development Remote SSH Remote Containers Remote WSL Docker Containerization tool Language support Thunder Client API Client Extention Visual Studio Code Extensionsの準備 MongoDB for VS Code for working with MongoDB, whether your own instance or in MongoDB Atlas. Microsoft.AspNetCore.R azor.VSCode.BlazorWas mDebuggingExtension
Visual Studio Codeでデバッグ環境を整備
フリーアイコンを表示 Node.js と Express を使用して Web API を構築する https://docs.microsoft.com/ja-jp/learn/modules/build-web-api-nodejs-express/
フリーアイコンを表示 Node.js と Express を使用して Web API を構築する https://docs.microsoft.com/ja-jp/learn/modules/build-web-api-nodejs-express/
フリーアイコンを表示 Node.js と Express を使用して Web API を構築する https://docs.microsoft.com/ja-jp/learn/modules/build-web-api-nodejs-express/
フリーアイコンを表示 Node.js と Express を使用して Web API を構築する https://docs.microsoft.com/ja-jp/learn/modules/build-web-api-nodejs-express/
フリーアイコンを表示 Node.js と Express を使用して Web API を構築する https://docs.microsoft.com/ja-jp/learn/modules/build-web-api-nodejs-express/
MongoDBに書き込み Node.js と Express を使用して Web API を構築する https://docs.microsoft.com/ja-jp/learn/modules/build-web-api-nodejs-express/
フリーアイコンを表示 Node.js と Express を使用して Web API を構築する https://docs.microsoft.com/ja-jp/learn/modules/build-web-api-nodejs-express/
Domain Driven Design実践 ドメイン駆動設計・開発の実践 DDD 指向マイクロサービスの設計
メッセージング・ミドルウェア 分散システム メッセージング ミドルウェア Point to Point Pub-Sub Message queue TCP (+SASL/TSL) Wire level protocol standard Advanced Message Queuing Protocol Remote Procedure Call TCP/IP (+Remote reference layer) Remote Method Invocation (RMI) CORBA ver. HTTP Dependent on server XMLHttpR equest (XHR) HTTP/2 Protocol buffers gRPC Internet InterORB Protocol (IIOP) Object Request Broker CORBA IDL WCF DCOM Point to Point Request Response Fan-out Message queue TCP Distributed Messaging (use broker) Apache Kafka WebSocket (Server Sent Events) SignalR Pub-Sub HTTP+TCP WebSocket Azure Web PubSub SignalR TCP Binary base protocol format MQTT 分散 ディレクトリ …* アーキテクチャ *分散トランザクションやリアルタイム・スケジューリングなど分散システムの実装によって複数の構成要素があります。
メッセージングの方向とコンテナ化 開発端末 Nginx (リバースプロキシ) 8080->8081 (as sample) Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Node (製品コンテナ) Alpine Linux Rust QR code App C# SVG free icon list App C# SVG icon coloring App 8080 8081 8082 8083 ステートフル・ミドルウェア 永続化層 MongoDB 永続化層 8082 8083 返答と 宛先 返答と 宛先 サービスのみ サービスのみ クライアントのみ 役割 すべてのコンテナのサービスの 方向が固定化している PubSubパターン AWS SQS Apache ActiveMQ AmazonMQ Azure PubSub MQTT Remote Procedure Call gRPC WCF CORBA コンテナ同士がサービスになっ たりクライアントになったりする ブローカーパターン Kafka RabbitMQ ブロードキャスト SignalR AMQP Apache Qpid
コンテナ化とは 可搬性、再利用性、拡張性など緻 密に設計されたのちに、サービス の方向をミドルウェアに依存させ た最小限のユースケース
WASM、WASI 02 PWA(Progressive Web Application)、 WebAssembly、 WebAssembly System Interface、Blazorの仮想化技術
X86, 64, Arm, RISC, … IDE Compiler プログラムが動くまで ActionScript, Ada, C#, Common Lisp, PicoLisp, Crystal, CUDA, D, Delphi, Dylan, Forth, Fortran, Graphical G, Halide, Haskell, Java bytecode, Julia, Kotlin, Lua, Objective-C, OpenCL, PostgreSQL's SQL and PLpgSQL, Ruby, Rust, Scala, Swift, XC, Xojo and Zig. Language Mono(includes Roslyn) Mono LLVM, Clang, Gollvm Cranelift, GCC(G++, GCJ, GNAT) Frontend LLVM, GCC(part of tools) Backend Emscripten, Cloud ABI WASM target Backend Node.js 、Wasmtime 、Wasmer Lucet、WebAssembly Micro Runtime WASM PWSIX (portable WebAssembly system interface) Browser Multiple platforms https://visualstudiomagazine.com/articles/2019/09/26/blazor-future.aspx
— docker founder : Solomon Hykes “If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task!” “2008年にWASM + WASIが存在していれば、 Dockerを作成する必要はありませんでした。それがど れほど重要かです。サーバー上のWebAssemblyは、 コンピューティングの未来です。” Docker Birthday #3: docker blog tweet of Solomon Hykes
X86, 64, Arm, RISC, … IDE Compiler プログラムが動くまで ActionScript, Ada, C#, Common Lisp, PicoLisp, Crystal, CUDA, D, Delphi, Dylan, Forth, Fortran, Graphical G, Halide, Haskell, Java bytecode, Julia, Kotlin, Lua, Objective-C, OpenCL, PostgreSQL's SQL and PLpgSQL, Ruby, Rust, Scala, Swift, XC, Xojo and Zig. Language Mono(includes Roslyn) Mono LLVM, Clang, Gollvm rustc_codegen_llvm2, GCC(G++, GCJ, GNAT) Frontend LLVM, Cranelift Singlepass GCC(part of tools) Backend Emscripten, Cloud ABI WASM target Backend Node.js 、Wasmtime 、Wasmer Lucet、WebAssembly Micro Runtime WAVM、 Wasm3 WASM PWSIX (portable WebAssembly system interface) Browser Multiple platforms
通信回数でステートフル State State State Stateful 接続 Stateful 接続 Stateful 双方向通信 Request State … 単一ループ State State State State Response Request Response Response Response Request
マイクロサービスで解決される側面 State State State Stateful 接続 Stateful接続 Stateful ミドルウェア マイクロサービス 双方向通信 Request State State State State State Response Request Response Response Response Request Infrastructure As Code Restore State ブルー Restore インクリメンタル デプロイ インクリメンタル デプロイ インクリメンタル デプロイ 最 小 範 囲 最 小 範 囲 クラウド(コントロールプレーンなど) グリーン
上映時間管理 ユースケースより精細な機能 State管理 Request Response スクリーン管理 States Request Response 空席管理 Screen Schedules ブルー/グリーン・テスト インクリメンタル・デプロイ 宣言型API 現在から最も早く上映さ れる映画の座席予約 Screen Seats Screen Master Request Response API開発者 Request Response 命令型API 命令型API API利用 命令型API 外部Program スクリーン=ScreenAPI(); foreachスクリーン{ スクリーン時間=SheduleAPI(s); foreachスクリーン時間{ スクリーン座席=SeatAPI(t, premier); foreachスクリーン座席{ if空いてたら{ result = 座席; break; } if座席{ break; } } } } return result; プレミアムシート 予約を機能削除 YAML プレミアムシート予約機能 が削除されました API利用側での PG改修が必須
コンテンツを配信するとは Platform データ・ プレーン ドメイン アプリケーション層 Webサーバー CDN RMI/gRPC XML-RPC <XML /> RPC 外部サービス 開発者 ブルー/グリーン・テスト インクリメンタル・デプロイ サービス サービス サービス サービス コントロール プレーン Contents Contents Contents XML Web Directory HTML Video Audio eBook HTML CSS JavaScript images State 管理 Function Data storage State 管理 機能群 Data storage Web App HTMLクライアント XMLクライアント メディアクライアント Native App HTMLクライアント XMLクライアント メディアクライアント RPCクライアント Mobile App HTMLクライアント XMLクライアント メディアクライアント RPCクライアント
コンテンツを配信するとは Platform Platform データ・ プレーン アプリケーション層 Webサーバー CDN RMI/gRPC XML-RPC <XML /> RPC サービス サービス サービス サービス コントロール プレーン Contents Contents Contents XML Web Directory HTML Video Audio eBook HTML CSS JavaScript images Web App HTMLクライアント XMLクライアント メディアクライアント Native App HTMLクライアント XMLクライアント メディアクライアント RPCクライアント Mobile App HTMLクライアント XMLクライアント メディアクライアント RPCクライアント HTML XML Image Video eBook Web Directory (Wget, rsync, FTP etc.) II Static Webで配信可能 AWS CloudFront* Azure CDN + Azure Front Door Service II 動的サイト アクセラレーション Akamai CDN Fastly KeyCDN Cloudflare CDN (Cloudflare Railgun) ※TCPコネクションのマルチプレキシング、 TCPコネクションのペリスタシー/プーリング、 およびTCPウィンドウサイズの最適化です CDN HTML Images CSS JavaScript Angular React Blazor Vue
リクエストレスポンス Platform アプリケーション層 サービス サービス サービス サービス HTML Images CSS JavaScript Angular React Blazor Vue CDN Webサーバー Http Request Http Response Http Request Http Response Http Request Http Response Blazor Server State 管理 Http Request Http Response
WebAssemblyはスタティックコンテンツ Platform アプリケーション層 サービス サービス サービス サービス HTML Images CSS JavaScript Angular React Blazor Vue CDN Webサーバー Http Request Http Response Http Request Http Response Http Request Http Response Blazor Server State 管理 Http Request Http Response WebAssembly Working Group
以降1月の後編に続く
Code 03 WSLのubuntuに配置したdockerイメージ内のnode に実装したWebアプリから、RustのQRコード生成プロ グラムを含むWebAssemblyを配信し、エッジサイドで QRコードを生成、編集します。
RUST
まとめ 04 今回は前編としてコンテナライゼーションの考え方とマ イクロサービスの設計およびコーディングによるコンテナラ イゼーションのサービスの基盤であるメッセージングミドル ウェアのお話をしました。 後編ではRustプログラミングの考え方をお話します。
CRÉDITOS: este modelo de apresentação foi criado pelo Slidesgo, inclui ícones da Flaticon e infográficos e imagens da Freepik Thank you 今後ともよろしくお願いします。 tetsuro.takao@processtune.com mvp.microsoft.com/en-us/PublicProfile/4029060 blog.processtune.com 73
Link ● slidesgo : 本プレゼンテーションのテンプレートWebサイト(本プレゼンテーションのURL) https://slidesgo.com/ (theme/eu-energy-strategy-business-meeting#search-space&position-2&results-73) ● GraalVM https://www.graalvm.org/ ● Install Docker CE on Ubuntu 20.04 https://lindevs.com/install-docker-ce-on-ubuntu/ ● Differences between GitHub Apps and OAuth Apps https://docs.github.com/en/developers/apps/getting-started-with-apps/differences-between-github-apps-and-oauth-apps ● pksunkara/octonode https://github.com/pksunkara/octonode ● Installing gh on Linux and BSD https://github.com/cli/cli/blob/trunk/docs/install_linux.md ● A Possible New Backend for Rust https://jason-williams.co.uk/a-possible-new-backend-for-rust ● EJS https://ejs.co/ ● pug https://pugjs.org/api/getting-started.html ● Handlebars https://jason-williams.co.uk/a-possible-new-backend-for-rust
Link ● Hogan.js http://twitter.github.io/hogan.js/ ● Twig https://twig.symfony.com/ ● Using template engines with Express https://expressjs.com/en/guide/using-template-engines.html
slidesgo : 本プレゼンテーションのテンプレートWebサイト(本プレゼンテーションのURL) https://slidesgo.com/ (theme/eu-energy-strategy-business-meeting#search-space&position-2&results-73) Cloud Native Computing Foundation (CNCF) : https://www.cncf.io/ Introducing gRPC, a new open source HTTP/2 RPC Framework : https://developers.googleblog.com/2015/02/introducing-grpc-new-open-source-http2.html Announcing HTTP/2 support in Azure App Service : https://azure.microsoft.com/ja-jp/blog/announcing-http-2-support-in-azure-app-service/ WHATWG : https://whatwg.org/ The LLVM Compiler Infrastructure : https://llvm.org/ llvm-project : GitHub https://github.com/llvm/llvm-project Configure options for the ASP.NET Core Kestrel web server : https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel/options?view=aspnetcore-5.0#http2-limits WebSocket : https://docs.microsoft.com/ja-jp/windows/uwp/networking/websockets Azure Web PubSub : https://azure.microsoft.com/en-us/services/web-pubsub/ Reference Links 1
Azure SignalR サービスとは : https://docs.microsoft.com/ja-jp/azure/azure-signalr/signalr-overview Cloud Native Apps (monthly resource) : https://github.com/microsoft/monthlyresources/?ocid=AID303759 HTTP/2 in Windows 10: Browser, Apps and Web Server : https://channel9.msdn.com/Events/Build/2015/3-88 Server Events : https://docs.servicestack.net/server-events#server-event-clients Azure Web PubSub Serviceを触ってみた : https://www.slideshare.net/ssuser293809/azure-web-pubsub-service Microservices and the First Law of Distributed Objects : https://martinfowler.com/articles/distributed-objects-microservices.html OASIS Message Queuing Telemetry Transport (MQTT) TC : https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=mqtt Use streaming in ASP.NET Core SignalR : https://docs.microsoft.com/en-us/aspnet/core/signalr/streaming?view=aspnetcore-5.0 Azure Web PubSub : GitHub https://github.com/Azure/azure-webpubsub gRPC services with ASP.NET Core : Visual Studio https://docs.microsoft.com/en-us/aspnet/core/grpc/aspnetcore?view=aspnetcore-5.0&tabs=visual-studio Reference Links 2
High-performance Services with gRPC: What's new in .NET 5 : https://channel9.msdn.com/events/dotnetConf/2020/High-performance-Services-with-gRPC-Whats-new-in-NET- 5?term=gRPC%20HTTP2&pubDate=year&lang-ja=true&lang-en=true gRPC Web with .NET : https://channel9.msdn.com/Shows/On-NET/gRPC-Web-with-NET?term=gRPC%20HTTP2&pubDate=year&lang- en=true&pageSize=15 .NET Core での gRPC のトラブルシューティング : https://docs.microsoft.com/ja-jp/aspnet/core/grpc/troubleshoot?view=aspnetcore-5.0 APACHE KAFKA : https://kafka.apache.org/ Quickstart: Create a serverless simple chat application with Azure Functions and Azure Web PubSub service : https://docs.microsoft.com/en-us/azure/azure-web-pubsub/quickstart-serverless?tabs=javascript NET での gRPC でサポートされているプラットフォーム : https://docs.microsoft.com/ja-jp/aspnet/core/grpc/supported-platforms?view=aspnetcore-5.0 Cloud Endpoints for gRPC : https://cloud.google.com/endpoints/docs/grpc/about- grpc#:~:text=gRPC%20is%20a%20high%20performance,create%20distributed%20applications%20and%20services. Using Docker in WSL 2 : https://code.visualstudio.com/blogs/2020/03/02/docker-in-wsl2 docker docs : https://docs.docker.com/ Reference Links 3
How to Deal with Lock Holder Preemption : https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.369.9589&rep=rep1&type=pdf Steve Jobs, 1955-2011 : https://www.theverge.com/2011/10/05/steve-jobs-1955-2011-2 Linux Kernel 5.15 Released with New NTFS File System, In-Kernel SMB Server, and More : https://9to5linux.com/linux-kernel-5-15-released-with-new-ntfs-file-system-in-kernel-smb-server-and-more Xerox Corp. v. Apple Computer, Inc., 734 F. Supp. 1542 (N.D. Cal. 1990) : https://law.justia.com/cases/federal/district-courts/FSupp/734/1542/1461830/ Apple Computer Inc. v. Microsoft Corp., 759 F. Supp. 1444 (N.D. Cal. 1991) : https://law.justia.com/cases/federal/district-courts/FSupp/759/1444/1472666/ Inflation Calculator : https://www.in2013dollars.com/us/inflation/1997?amount=1 U.S. Dollar to Japanese Yen Spot Exchange Rates for 1997 from the Bank of England : https://www.poundsterlinglive.com/bank-of-england-spot/historical-spot-exchange-rates/usd/USD-to-JPY-1997 Information Anxiety 2 (Hayden/Que) 2nd Edition : https://www.amazon.com/Information-Anxiety-2-Hayden- Que/dp/0789724103/ref=sr_1_1?ie=UTF8&qid=1341674668&sr=8-1&keywords=Information+Anxiety+2 それは「情報」ではない。―無情報爆発時代を生き抜くためのコミュニケーション・デザイン : Amazon Link Software Development for Small Teams : Google Books Google Book Link Reference Links 4
What Is Domain-Driven Design? : O'Reilly https://www.oreilly.com/library/view/what-is-domain-driven/9781492057802/ch04.html Steve Jobs, 1955-2011 : https://www.theverge.com/2011/10/05/steve-jobs-1955-2011-2 Wasmtime:A small and efficient runtime for WebAssembly & WASI https://wasmtime.dev/ Fastly のネイティブ WebAssembly コンパイラ & ランタイム「Lucet」を発表 https://www.fastly.com/blog/announcing-lucet-fastly-native-webassembly-compiler-runtime WebAssembly Micro Runtime(WAMR):組み込み向け軽量ランタイム(JIT除く) https://github.com/bytecodealliance/wasm-micro-runtime WASMER https://wasmer.io/ WebAssembly System Interface (WASI): Node.js v17.1.0 documentation https://nodejs.org/api/wasi.html Azure Active Directory Domain Services のマネージド ドメインのグループ ポリシーを管理する https://docs.microsoft.com/ja-jp/azure/active-directory-domain-services/manage-group-policy 移動ユーザー プロファイルの展開 https://docs.microsoft.com/ja-jp/windows-server/storage/folder-redirection/deploy-roaming-user-profiles#step-4- optionally-create-a-gpo-for-roaming-user-profiles UBUNTU 12.04 ACTIVE DIRECTORY AUTHENTICATION http://koo.fi/blog/2013/01/06/ubuntu-12-04-active-directory-authentication/ Reference Links 5
Ubuntu Linux 仮想マシンを Azure Active Directory Domain Services のマネージド ドメインに参加させる https://docs.microsoft.com/ja-jp/azure/active-directory-domain-services/join-ubuntu-linux-vm Android で MSAL を使用してクロス アプリ SSO を有効にする : Microsoft Docs https://docs.microsoft.com/ja-jp/azure/active-directory/develop/msal-android-single-sign-on Containers in the enterprise:Results from research conducted in 2020 by IBM Market Development & Insights https://www.ibm.com/downloads/cas/VG8KRPRM Reference Links 6

WebAssemblyとBlazor 、WebAssembly System Interfaceでコンテナライズの設計を解説

Editor's Notes

  • #2 古くから考えられていた分散コンピューティングという概念は、現在では多くのクラウドインフラストラクチャのおかげで設定レベルで利用できるようになりました。クラウドネイティブなソリューションの利点であるスケーラビリティやモビリティ、セキュリティ、アベイラビリティ、継続的インテグレーションなどの実装の多くの部分から開発者は解放されたものの、ソリューションアーキテクトがこれまで以上に「クラウドネイティブなソリューションは分散コンピューティングであること」を意識する必要があります。 分散コンピューティングのアーキテクチャの中でソリューションアーキテクトが最も気にしなければいけないことはメッセージングです。一方、最も多いイベントドリブンプログラミングを行う開発者を人員配置することは、最も安全にプロジェクトを進行していく方法のひとつとしてプロジェクトマネージャの関心ごとのひとつです。さらに、開発者はイベントドリブンプログラミングを行う場合、分散コンピューティングで「いつ」「誰の」イベントが「誰に」飛ぶのかを意識しながら問題解決領域内で分散しているステートの一貫性を保つように実装設計し構築する必要があります。そのためクラウドのソフトウェア開発に携わる人間は、立場に関係なくメッセージング・ミドルウェアの知識と、それぞれのミドルウェアをどのように構成するかという部分について見識を深める必要があります。 次に、メッセージング・ミドルウェアを理解すると、今度はそれをどのようにコンテナライズすればよいのか?という疑問に出会うことになります。コンテナライズはソフトウェアが基盤に依存することなく動くように構成することで、クラウドネイティブなソリューションの利点を最大限生かすための概念のひとつです。 dockerやkubernetesはコンテナライゼーションの道具なので、その操作を覚えてもコンテナライゼーションを設計できるわけではありません。また、コンテナライゼーションを設計していないコンテナをそれらのツールで作成しても、クラウドネイティブなソリューションの利点を活かすことは難しく、かえってコンテナライゼーションに関わる余計な作業が増えるだけです。 そこで、今回は身近でかつ開発環境を選ばないWebAssembly(WASM)やWebAssembly System Interface(WASI)を例にコンテナライゼーションの設計のお話をします。
  • #3 【読む】
  • #4 本日は、まず最初にコンテナの設計の話をします。【クリック】 コンテナライゼーションの基本はどこでも動くように、基盤を抽象化するということです。最もわかりやすいのはCドライブにログを書かないということです。ロギング機能がサービスとして存在していれば、どこに配置したとしてもロギング・サービスを利用するプログラムはいつでもどこからでも機能を呼び出すことができます。その際プログラムは書き込みたいログの内容をサービスに伝える必要があり、その技術としてメッセージングという考え方があります。メッセージングはサービスと利用するプログラムの間だけでなく、サービスとサービス間でやり取りすることもでき、イベントドリブン・プログラミングにおいて重要な役割を果たします。 メッセージングの基盤の設計にメッセージング・ミドルウェアという概念があり、その実装としてKafkaやAzure Web PubSub、RabbitMQのようにメッセージングの中間にブローカーを置くタイプ、サービス側から利用側にメッセージングするSignalR、その逆の方向にメッセージングするgRPCなどがあります(SignalRは両方向構成できますのでgRPCのように構成することができます)。 これらのメッセージングの方向の違いを理解しソリューションを設計していく必要があります。設計を忠実に実装するために的確なメッセージング・ミドルウェアを選定すべきで、そこに雑音が入ると苦労するのは実装者です。また、さまざまな外的要因からメッセージング・ミドルウェアが決まっている状態で設計を行う必要がある場合であっても、その方向とそれによる特性を理解していれば実装時に無駄な人件費を増大させない設計はできます。ここではその設計の例として、マイクロサービスをドメインドリブンアーキテクチャで設計していく方法をお話します。 分散コンピューティング環境であるクラウドにおいて、その利点を活用しようとする技術のひとつとしてマイクロサービスがあります。マイクロサービスをドメインドリブンデザインで設計した場合、問題解決領域をユーザーストーリーやユーザーストーリーを構成するユースケースをバウンダリーコンテキストとして定義し、バウンダリーコンテキストを構成するエンティティやバリューオブジェクトを定義して、的確なタイミングでエンティティやバリューオブジェクトを収集するアグリゲーターを必要に応じて設定して、バウンダリーコンテキストをファクトリーからサービスとして配信する手法を採ります(この話の詳細は、ラボの今年の6月の「DDDとMVCの関係」を参照してください)。この際、必要に応じて複数のサービスでステートフル・ミドルウェアを構成するわけですが、そのステートを単一または複数のメッセージング・ミドルウェアでメッセージングの方向を正しく設計・実装します。ステートフル・ミドルウェアをうまく構成することで開発範囲が激減し、開発、運用ともコストが軽減します。AWSでもAzureやGCPであっても、皆さんが設計したソリューションを実装するメッセージング・ミドルウェアを提供していますし、Kafkaなどでカスタム実装も可能です。 また、各クラウドプロバイダーの技術資料や個人ブログなどから製品の取り扱い手順がたくさん提供されています。このステートフル・ミドルウェアの単位とメッセージングの方向でコンテナライゼーションの範囲が決まります。このコンテナラーゼーションの範囲を意識したコンテナは、そのオーケストレーションも明確で継続的インテグレーションを計画しやすくなります。
  • #5 クラウドネイティブなソリューションの利点を活用できるアーキテクチャはマイクロサービスだけではありません。ここではマイクロサービスを例にコンテナライゼーションを設計していきますが、RESTやSPAといったアーキテクチャにおいてもコンテナラーゼーションを設計できます。設計のポイントはステートをどのように管理するか?という点で異なります。マイクロサービスがステートフルミドルウェアという概念でステートの一貫性(Consistency)や不可分性(Atomicity)、永続性(Durability)や独立性(Isolation)を確保しようとしているのに対し、RESTはステートを永続化する箇所ついては自由です。cookieでもview stateやサービス側のDBでもかまいません。REST APIにおいてステートレスWeb APIがたまたまサービス利用側との連携でステートフルに振舞っています。また、SPAはそもそもWebでステートフルに振舞うためのステートの細分化を設計・実装する必要があり、ステート更新がブラウザやサーバー、またその両方向から行える仕組みなので、マイクロサービスのようにステートの永続化層はサービス固有というわけではなく、RESTのもうひとつの形ということが言えます。 そのため、この2つをコンテナライズすることはできますが、業務と業務を構成するステート、ステートのACIDについて可搬可能なコンテナを設計することは非常に困難です。業務を局所化し、そのステートの永続化層を内包したコンテナを作成しにくいからです。AngularやReactを使っているからSPAではなく、業務ステートを細分化してその組み合わせでユースケースを表現できる設計をすることがSPAです。 そのため、WebAssemblyを例にしてコンテナライゼーション設計の解説をしていきます、コンテナライゼーションは基盤仮想化ですので、仮想化技術の視点からコンテナライゼーションの仮想化技術を読み解いていきます。
  • #6 dockerイメージはコンテナの一種です。中には非常に軽量なAlpine linuxが入っており、nodeを追加することでWebサーバーを構築できます。このサーバーからRustで作成したQRコード生成のプログラムを配信するWebAssemblyコンテンツを追加します。そして、そのWebAssemblyにSystem Interfaceを実装してWindowsで動かすことでマルチプラットフォームであることを確認します。
  • #8 このWebページはIBMの記事ですが、コンテナライゼーションの基礎を非常にわかりやすく解説しています。このページの中でマイクロサービスとコンテナライゼーションの話をしています。【読む】 コンテナの設計で重要なことはその範囲の定義です。たとえばNginxでサービスエンドポイントを構成し、リバースプロキシやロードバランサーを作って、マイクロサービスのひとつのWebサービスをNodeで作った場合、それぞれをDockerイメージで作成することもできますし、同じコンテナで構成することもできます。この際のNginxはサイドカーの役割を果たしますのでNodeのサービスのサイドカーの役割であれば同じコンテナで設計しても正しい設計と言えますし、Nginxはルートの役割を果たしているのだからサービスメッシュ設計パターンであれば別々のDockerイメージでも正しいと言えます。つまり、コンテナライゼーションの範囲の定義は、マイクロサービスの設計に依存します。マイクロサービスの設計の結果、そのサービス単位でコンテナを構成することで、クラウドネイティブなソリューションの活用の最も近道となります。
  • #9 マイクロサービスの設計では、ステートフル・ミドルウェアを構成する必要があります。ステートフル・ミドルウェアは各サービス固有の永続化層から取り出した各ステートを必要に応じて適正に合成してユーザーに提供する手法です。ステートフル・ミドルウェアの説明のため、非常にシンプルな例ですが、Nginxのリバースプロキシから一番右のSVGアイコン色付けのWebアプリに飛ばすようなアプリを例にしています。このアプリはSVGファイルを色付けするアプリで、左の2つのサービスを利用しています。一番左はRust言語で作成されたQRコードを生成するサービス、真ん中はSVGのフリーのアイコンを取得するサービスです。 このサンプルはすごく簡単に作れますのでぜひやってみてください。
  • #10 WSLを設定してubuntuをストアからインストールします。その後、ubuntuにdockerを作る作業を行います。 最初にツールはhttps(HTTPS接続)とca-certificates(SSL接続)、gnupgp(鍵暗号化、複合化、署名ツール)、lsb-release(バージョン確認)、curl(通信クライアント)を入れておきます。 次にDockerをインストールするためにキーの取得を行います。最後にインストールできるイメージを確認してインストールします。
  • #11 NginxやNodeはDockerからオフィシャルイメージが提供されていますので、pullしてrunしてコンフィグを編集するという所要時間5分の作業でNginxの設定は終わります。
  • #12 confファイルをvimで開いてhttpブロックのServerセクションを追加するだけでリバースプロキシは設定できます。実環境ではホスト側のファイアーウォールの設定が必要です。このサービスエンドポイント内でもファイアーウォールの設定は「ufw enable」「ufw allow」「ufw default deny」の数行で設定できますが、サービス同士が通信するパターンではなく、サービスメッシュを設計する場合各サービスからサービスメッシュエンドポイントにサイドカーの機能を移動させる必要がありますので、それなりのセキュリティ設計が必要になります。可搬性を意識してこのタイミングではファイアウォールやロードバランシングを設定をしません。コンテナを実際に配置する際に設定するようにします。
  • #13 Nodeも同じくDockerからオフィシャルイメージが提供されていますので、pullしてrunしてexpressをインストールするという所要時間5分の作業でホームページが表示できます。【クリック】ただ、この段階では既定の3000ポートでホームページを表示しますので、後程80に変更して8081ポートがDocker内部の80ポートに飛ぶようにします。【クリック】
  • #14 実際の画面でも3スクロール半程度でホームページを表示できます。
  • #15 pullは最初の一回だけでいいのでやっておいてrunします。【クリック】コンテナに入ります【クリック】/home/nodeに移動してAlpine linixを最新にします【クリック】
  • #16 Nodeのパッケージマネージャーは、最初の一度だけ初期化します。【クリック】ここではリターンキーで進んでいますが、必要に応じてパッケージ名や説明、作成者などを入力しパッケージ情報を作成します。書き込み場所の確認とjsonファイルに書き込まれる内容が表示されます。
  • #17 Jsonファイルに書き込むNodeパッケージマネージャーの情報の内容に「y」で確認すると、新しいバージョンがあることを警告しますが、無視してexpress-generatoテンプレートをインストールします。【クリック】 カレントディレクトリでテンプレートを使ったWebページを作成します。作成の確認に「y」で作成を開始します。
  • #18 テンプレートでリソースを作成し終えたらNodeのバージョン間の競合を解決します。【クリック】脆弱性の警告が出るので監査内容を修正します。
  • #19 脆弱性が「0」になってWebをスタートさせると3000ポートでWebリクエストを待ち受けていることが表示されます。
  • #20 ブラウザから8081→Docker→nodeに要求が転送されていることを確認できます。
  • #21 続けてgitも入れてしまいます。Gitのインストールははさらに簡単です。ここで作成したホームページをGitHubにコミットする方法は後述します。コミットはGit CLIを使いますので、いったんCtrl+CでWebを終了しAlpine linuxを最新にしてgitをインストール、再度Alpine linuxを最新にした後に.gitignoreファイルも編集するのでここでvimも入れておきます。最後にもう一度Alpine linuxを最新にしておきます。この状態でDockerイメージを保存しておきます。
  • #22 保存にはコンテナの保存とイメージの保存がありますが、今回のコンテナライズはプロジェクトに新規開発メンバーが入った時の開発環境配布についてもCD/CIと同様に考慮すべき点と思いますので、ここではイメージの保存を行います。新規メンバーがチームに入った時にすぐにコーディングに取り掛かってもらうことが理想です。プロジェクトのコストのほとんどが人件費なので、このような工数の削減は非常に重要です。Dockerコンテナから抜けて、現在のnodeイメージの状態をアプリケーション名でリポジトリ名、バージョン名でタグ名を指定したイメージとして作成するためnodeコンテナをコミットします。pullしたnode:latestイメージが別のイメージとしてリポジトリ名、タグ名になって保存されます。その後コピーした方のイメージをtarファイルとして保存して、プロセスをKillしてコンテナを廃棄します。後述しますが、nodeの方を使ってQRコードアプリとSVGフリーアイコンリストアプリを作成します。それでは、実際にステートフルミドルウェアを設計します。
  • #23 ログインユーザーがどのようなQRコードを生成しどのような色付けしたかは8081でなく8083に永続化されます。またどのようなフリーアイコンを選びどのように色付けされたのかは8082に永続化されます。8081には、そのアイデンティティがログインしているかどうかだけが永続化されます。8081は、ユーザーがログインしている場合に8082や8083に問合せを行います。このように必要な時に必要な情報のみを参照してコンテキストを生成する手法をステートフルミドルウェアと言います。 このステートフル・ミドルウェアは8081が制御するパターンもありますが、エンタープライズ・ソリューションではメッセージング・ミドルウェアを構成してステートフル・ミドルウェアを実装していくケースが多くあります。
  • #24 先ほどのログインユーザーのステートはマイクロサービスとして設計します。この設計のプロセスの一例としてドメインドリブンデザインでの設計を解説します。 ドメインドリブンデザインでは、大きくドメインを構成して、コンテキストを設計しモデルを作成します。 ここで注意していただきたいのは、ステートフルミドルウェアを8081が制御するように実装する方法であっても、メッセージングミドルウェアを使って実装する方法であってもステートフルミドルウェアの設計プロセスは同じということです。
  • #25 DDDの入り口としてドメインやサブドメインを構成する複数(または単一)のバウンデッド・コンテキストを説明する4つの設計概念(エンティティ、バリューオブジェクト、サービス、イベント)の関係性をお話しします。 問題解決領域であるドメインは複数のサブドメインで構成されます。このサブドメインはユーザーストーリーから作成することができます。この方法がDDDのすべてではありませんが、DDDを最も理解しやすい方法なので、まずはこの方法で習得してからほかのアプローチを検討してみてください。 ログインユーザーがQRコードを生成するというユーザーストーリーにはログインするというユースケースとQRコードを生成するというユースケースがあります。たとえばQRコードを生成するというユースケースで扱う情報をバウンデッドコンテキストといいます。QRコードを生成するためのバウンデッドコンテキストにはQRコードそのものを表すエンティティとログインユーザーを表現するエンティティがあります。エンティティとして表現する方法のほかの表現としてバリューオブジェクトという表現方法があります。設計によって、どちらで表現しても構いませんが、ログインユーザーのIDが異なれば別のユーザーと判別できますからバリューオブジェクトとして定義できるかもしれません。バリューオブジェクトとは複数のデータの塊の形が同じで、そのうちのいくつか(またはひとつ)が異なると別物であると一意に決まるログインユーザーのようなものを表現するときに設計に利用できる概念です。
  • #26 バウンデッドコンテキストはユースケースとして設計する方法があります。ドメイン・ドリブン・デザインでは、サブドメインとして分割された問題解決領域で必要な情報はそれぞれが関連しているのかどうかを明示する必要があります。図でいうところのログインユーザーというバリューオブジェクトは、サブドメインの中でバウンデッドコンテキスト間に共通する情報です。このようにユースケースごとに共通するエンティティを明示していく作業をコンテキストマッピングと言います。
  • #27 SVGエンティティや色エンティティにはIDのようなものはありません。一意である必要が無いからです。色はログインユーザーが決定する情報なのでログインユーザーにはアイコンとアイコンの色、QRコードとQRコードの色があります。また、アイコンもQRコードもSVGで取り扱いますのでログインユーザーにはそれぞれコードを生成するソースの文字列とフリーアイコンのアドレスの属性を持ちます。ログインユーザーのアイデンティティプロバイダーの認証URLは、ユーザーがログインに使用したものになります。
  • #28 このサービスとイベントによってメッセージングの方向が決まりますので、コンテナの範囲が決まります。解説を簡略化するためコンテナを先に説明しましたが、本来はドメインからサブドメインに分割していきます。つまり、SVGアイコン色付けドメインのSVGフリーアイコンのリスティングユースケースに分離設計して、このユースケースのバウンデッドコンテキストをモデリングしていくという流れです。SVGフリーアイコンのWebサイトから取得したSVGを一覧するサービスですが、SVGフリーアイコンのWebサイトに問い合わせるのはこのサービスが呼ばれた時になります。そして、呼ばれるときにアカウントに紐づけられたアイコンをSVGフリーアイコンのWebサイトに問い合わせます。そして、何かしらのエラーが返ってきたときに予備的な何等かの画像を返すようにしないと、このサービスを呼び出した元は直接SVGフリーアイコンのWebサイトに問い合わせるのと変わりません。このサービスにはアカウントとアカウントに紐づいたSVGアイコンのURL、SVGアイコン画像、アカウントが編集した色が永続化されます。この永続化層とサービスの入出力口をつなぐ部分がサービスリポジトリと言います。
  • #29 このサービスにはアカウントとアカウントに紐づいたSVGアイコンのURL、SVGアイコン画像、アカウントが編集した色が永続化されます。この永続化層とサービスの入出力口をつなぐ部分をサービスリポジトリと言います。サービスリポジトリはこのサービスのバウンデッドコンテキストのログインユーザーモデルを持っています。今回はたまたま同じ形をしたログインユーザーモデルがログインサービス側にいます。バウンデッドコンテキストが異なると関連するエンティティやバリューオブジェクトは異なることが重要です。ユースケースによって関心ごとや構成する属性が異なるからです。解説は割愛しますが、たとえばシネマコンプレックスのスクリーン情報はユーザーにとってはいつ何が上映されているかに関心があると思いますが、シネコン側からすればそれに加えキャパシティや車いすの席数も必要です。このようなケースでバリューオブジェクトを設計するとドメイン内で余計な情報を持ち歩くアプリケーションを作成してしまいます。もちろんスペックやセキュリティの側面から好ましいとは言えません。そのため、サービスリポジトリではそのサービスが扱うバウンデッドコンテキストのモデルの形で永続化することになり、それを他のバウンデッドコンテキストのモデルと合致させるための翻訳はファクトリが行うことになります。外部ソースやそのサービスの永続化層のからのデータなどを紐づけして、そのサービスのモデルのインスタンスに格納していく作業を行うのはアグリゲートです。
  • #30 ドメインドリブンデザインによってサービスを構成するサービスリポジトリ、ファクトリ、アグリゲートの役割が明確化するとイベントの発生タイミングとイベント同士の関連、守られなければならない順が明確化します。このサービスでは呼び出されたタイミングで発生するイベントがトリガーになり、永続化層にアカウントのURLを問合せて、取得したURLへリクエストを投げます。そのリクエストの返答がないと永続化層へ結果を書き込めません。また、返答後にステートフルミドルウェアへの最新のSVG情報を提供します。このようにイベントの発生タイミングと順番を明示しておくことが重要です。【クリック】ただし、ステートフルミドルウェアに情報提供するタイミングについてフリーアイコンサイトに問合せの返答を待つ場合は一度のリクエストレスポンスですが、待たない場合はフリーアイコンサイトへの問合せの返答が来たら情報を更新するので、レスポンスは2回になります。この部分はメッセージングミドルウェアを利用するか、このサービスを利用する側で最新の情報の取得を待つ必要があります。 制約をつけて「ユーザー操作による最新情報の取得」、「常に最新の情報を取得し、取得できなかった場合にのみ永続化層のデータを使う」などの対応はありますが、マイクロサービスにそのような制約を設けるとマイクロサービスの可搬性、再利用性を失います。そのため、このサービスには最新の問合せを行うかどうかのオプションも設ける必要があります。
  • #31 開発環境では、永続化層はJSONをテキストファイルに書き込む程度でも問題ありませんがコンテナの外部のストレージをマウントするとコンテナの可搬性が失われます。そこで、SVGフリーアイコンリスト・アプリのコンテナにはmongoを仕込みます。nodeと同じようにmongoもDockerからオフィシャルイメージが提供されていますので、mongoのコンテナにnodeをインストールするという非常に簡単な作成方法があります。【読む】【クリック】ポート【クリック】今回はnodeはインストールされていませんので、curlでnodeを取得してインストールします。curlも入っていないのでこの4行でnodeをインストールします。【クリック】後はnodeのときと同じです。
  • #32 expressでWebアプリの作成が終わったら今度はapp.jsを編集してポートを80に直します。同じように8081の3000も80に直します。「sudo docker exec -it svgfreeicondb /bin/bash」で中に入って「vim app.js」でapp.jsをvimで開きます。【クリック】「i」で編集できるようになりますから、この1行をapp.setの一番下に追加して「esc」「:」「w」で保存して「:」「q」でvimを終了します。
  • #33 ここでmongoshと打ちます。【クリック】現在のmongoの状態が表示できますので、接続情報の場所を覚えておきます。【クリック】
  • #34 Visual Studio CodeのExtentionで先ほどの接続情報を使ってdockerのmongoに接続できていることを確認してください。【クリック】
  • #35 では、この3つの動きを確認してみましょう。ステートフルミドルウェアは後に様々なメッセージングミドルウェアに移植できるように簡単なwebアプリをひとつ作って各コンテナからのメッセージを受け付けて、宛先にバイパスして、返答が返って来たら待ってるコンテナに返すだけのシンプルなものを用意します。今度はDockerをホストしているWSLのホストのWindows側に小さなアプリを作ります。
  • #36 こちらも非常に簡単です。3行で開発に入ることができます。開発証明書を入れても4行なので非常に簡単です。開発証明書は「dotnet dev-certs https --trust」で入れます。
  • #37 その状態でVisual Studio Codeを開きProgram.csを開きます。このapp.MapGetの部分がルーティングになりますので、先ほどの「http://localhost:5268」の「/weatherforecast」をブラウザで閲覧します。 動作が確認出来たら、このapp.MapGetの部分をコピーしてメッセージングミドルウェアのプロトタイプを作ります。このステートフルミドルウェアが稼働するのは.NETフレームワークが入っているサーバーということに注意してください。メッセージングミドルウェアを実装する場合には、Apache Kafka、RabbitMQのようなブローカーにメッセージを送るタイプ、ブローカーを意識しないPaaS系のAzure PubSubのようなメッセージングの方向が決まっているもの、双方向に直接メッセージングが可能で受信側が送信元になれるSignalRのようなもの、受信側が固定化されたAWS SQSやApache ActiveMQ、そのマネージドサービスであるAmazonMQ、AMQP対応のApache Qpidなどものすごい量のアーキテクチャを選択できます。ソリューション内のサービスの方向を整理して設計するので、設計に必要なメッセージングミドルウェアのプロトタイプは必ずシンプルなものを実装します。
  • #38 appsettings.jsonにサービスエンドポイントを定義します。キーは特にポートと同じでなくても良いです。この設定値の情報は、minimalテンプレートにはswaggerが付いてますので、このAPI利用者用に情報提供のAPIも作っておきます。
  • #39 swaggerは「/swagger」にルーティングされています。【クリック】settingsInfoを開き【クリック】Try it outを選択して【クリック】Executeを実行します【クリック】設定値を確認することができます。【クリック】
  • #40 エラーなども用意していますがメッセージング部はいたってシンプルです。【クリック】デバッグのため、受け取った文字を返していますが取得できていることが確認できるので、後程コメントアウトして引数で指定された送信先にメッセージを転送するようにします。
  • #41 8082はリクエストを受けて、アカウントがアイコンを設定していなければ、設定してもらうようにある程度の量のアイコンを返してやる必要があります。また、あればそのアイコンひとつを返してやります。なのでMongoDBに問い合わせる、無かったら10個程度フリーアイコンサイトから取ってきてそのまま返す、あったらそのアイコンをフリーアイコンサイトから取ってきてDBに保存し返すようにします。常に最新のアイコンを返します。エラー時にDBのものを返すのですが、この一連の作業は呼び出し側から制御できるようにして、最新を問い合わせない、エラーをそのまま返す等の選択ができるようにします。そこでいったん8082に入ってWebアプリをGitHubにアップします。こちらも簡単な作業ですので実際にやってみてください。
  • #42 GitHubは組織でチーム開発ができます。そのためGitHubの組織アカウントをお持ちの方もAzure Active Directoryの方も開発に参加できます。コミット等の操作はCLIで行いますのでGitHub CLIをインストールします。dockerと同じようにキーを取得後ダウンロードしてインストールします。ただし、今度はdocker内のAlpine Linuxで行いますのでsudoは使いません。
  • #43 すでにアプリのスケルトンはできているのでそのままコミットします。
  • #44 作業効率の良い環境で作業してください。私はWindowsのVisual Studio Codeでの作業に慣れているのでGitHubからダウンロードして作業をしています。まず、nodeのバージョンを確認してください。linux側と同じなら問題ありません。また、node_modulesフォルダ、.gitignoreファイルやhttp-errorのnodeモジュール、expressのbody-parserや開発証明書も追加します。【クリック】.gitignoreファイルはdotnet newで作ります。【クリック】実際この6行打つだけで画面が出ます。
  • #45 今度はWindows側で開発するのでVisual Studio CodeのExtensionを追加しておきます【画面説明】
  • #46 GitHubからダウンロードしてきたフォルダをVisual Studio Codeで開いてデバッグペインを開くとデバッグ方法の選択肢が表示されます。【クリック】Run and Debugで選択ツールバーが表示しますので、EdgeかChromeを選択します。【クリック】launch.jsonが開くのでurlのポートを80に直してAdd configurationを選びます。【クリック】選択肢が表示されますので、リストの一番下まで移動し「Run “npm start” in a debug terminal」を選択します。【クリック】最後に出来上がった2つをcompaundsでつなげてデバッグリストの名前を選択して実行します。【クリック】terminalで200、スタックにブラウザとnpmが起動していることを確認します。終了はデバッグのツールバーで2つのスタックを終了させます。
  • #47 マイクロソフトlearnにそのものズバリのコンテンツがありますので、詳細はそちらを参照してください。【クリック】まずapp.jsにPOSTとGETの入り口を作ります。body-parserを定義してjsonメソッドを呼び出します。これでリクエストのjsonを解析できます。【クリック】
  • #48 GETはアドレス「/freeIcons」にアカウントの有無で、返すsvgの個数を変更する処理を行ってから、ひとつであればmongoに保存してレスポンスを返すという処理です。【クリック】ポイントは「req」「res」「next」でそれらをコントロールできる点です。【クリック】リクエストはそのままクエリストリングをシンプルに指定できますし、【クリック】nextキーワードによって同期処理が保証されます。 ドメインドリブンデザインのサービスとイベントで定義された処理順がそのまま実装できます。【クリック】nextキーワードで次の処理に行くとフリーアイコンが取得できたことが保証されているのでmongoに保存、およびレスポンスの設定ができます。ここでもレスポンスにはendメソッドがあるのでヘッダーの書き込みは必ずレスポンスを返す前に行われることが保証されます。
  • #49 今回はAPIなのでViewは持ちません。デバッグはThunder Clientを使います。Thunder Clientを一番最初に使うときはアイコンは表示されていないので「Ctrl+Shft+P」で起動してピン止めしておいてください。【クリック】デバッグでブラウザを表示してから、New RequestでGet、localhost/freeIconsでSendボタンをクリックするとレスポンスが返ってきます。【クリック】また、アカウントをクエリストリングで指定するとひとつだけレスポンスが返ってきます。【クリック】【クリック】
  • #50 POSTはもう少し簡単です。【クリック】urlを指定したapp.postメソッドにリクエストのbodyを取得するそうにするだけです。body-parserによってJSONを非常に簡単に操作できます。【クリック】GETと同じようにThunder Clientでデバッグします。今度はヘッダのContent-TypeとBodyのJSONを設定してPOSTでlocalhost/seticonをsendします。
  • #51 SVGを取得する部分を作成します。【クリック】外部APIリクエストにaxiosとSVGのXML部分を抜き出すのにexpress-xml-bodyparserを使うのでVisual Studio Codeのターミナルを使ってインストールします。また、今回は使いませんが「npm i svgson」をやっておきます。【クリック】外部‘Webにリクエストを投げる部分とレスポンスを取得する部分は、10個と1個の違いなのでほぼ同じですが、axiosの使い方に少し工夫します。【クリック】svgを受け取る際に同期処理としてresponse.dataを待ちます。また、Expressサーバーが次の処理に進むのはファンクションの中で10個取得したかどうかを判定しています。【クリック】実行するとひとつ取得と10個取得ができていることを確認できます。さきほどsvgsonを今回やらないと言いましたがこのSVGのXMLはサニタイズされているので後処理が必要です。その後処理を行うためにsvgsonを使うので、またの機会に解説します。
  • #52 次にmongoです。【クリック】Dockerの8082のデータベースを起動しておいてVisual Studio CodeでMongoDB Extentionを起動します。先ほど作成したコネクションを選択して、Add Databeseを選択します。Playgroundが開きますので、編集してDBを作成して行きます。【クリック】database「SVGServiceDB」、collection「UsersState」、createCollectionはそのままで「db.UsersState.Insert」を追加します。フィールドはaccountとurlだけ入れておきます。値は好きなものを入れておきます。先ほど設計した内容では、既定で「アイコンを取ってきてからDBに書き込み」です、また最新を問い合わせるオプションはまだ実装していないので、この状態でプログラムの開発準備が整いました。実行します。【クリック】Resultが表示されますので、Playgroundの3点リーダーを使って画面を操作します。【クリック】追加されたことを確認します。
  • #53 npm I mongodbでインストールした後にrequireでインポートしてコードで使用します。【クリック】処理ではmongoClientの接続、アカウントの有無確認アップデートまたは追加の処理を追加するだけです。
  • #54 処理の構築でソリューションエンジニアやプロジェクトマネージャはソースコードを読む必要はありません。品質を保証するのは設計と設計に合致したサービスの方向とタイミング、実行順です。特にマイクロサービスの場合、これまで見てきたように非常にシンプルな作業でコンテナ化が可能です。コンテナライゼーション時代のマイクロサービス設計がドメインドリブンデザインによって品質保証を行うことができることが確認できたと思います。実際に今回のような実践は様々な情報として提供されています。
  • #55 ドメインドリブンデザインのサービスとイベントで各サービスがどの相手と通信するのかが明確になりますから、サービス単位に設計されたコンテナのメッセージングの方向が稼働するミドルウェアを決める動機になりえます。この時にステートフルミドルウェアを構成するサービスが稼働するメッセージングミドルウェアを正しく選択する必要があります。バズワードに惑わされることなく、メッセージングモデルの特性を知っておくことが重要です。 現在利用されている代表的なアーキテクチャはメッセージングミドルウェアという概念から派生しています。メッセージングミドルウェアの概念として、ポイント・ツー・ポイント、ファンアウト、リクエスト/レスポンスなどがありますが組み合わせて使うことが一般的で、各クラウドベンダーサーバーレスアーキテクチャとして用意するコントロールプレーンやサービスで実装されていますし自作することもできます。【クリック】Kafkaはブローカーモデルなので、パブサブパターンやキューを実装できますし、SignalRはPubSubパターンを実装できます。またAdvanced Message Queuing Protocolはポイント・ツー・ポイント、パブサブパターンやキューを実装できます。
  • #56 今回8081のSVGカラーリングアプリがSVGを呼びました。また後程QRCodeを呼び出します。このステートフルミドルウェアのアーキテクチャ選定はドメインドリブンデザインの設計時に決定できます。ブローカー
  • #58 コンテナ化の目指すところはユースケース別のサービスと同じく機能別にも考慮されています。
  • #59 これは2019年の記事ですが、コンテナ化の考え方が拡張されてきた経緯などが書かれていなす。
  • #60 ドッカーの創始者のソロモン・ハイクスのツイートも有名です。
  • #62 Application Binary Interface
  • #67 プラットフォームから配信するコンテンツがスタティックなコンテンツであれば、サービスサイドの動的なコンテンツ作成を必要とることなくAzure CDNなどのContents Delivery Network(CDN)を利用することができます。【クリック】また、CDNの中には動的サイトアクセラレーション(DSA)というサービスサイドレンダリングを行う機能(サービスサイドプログラムや外部Web APIを利用したサービスサイドマッシュアップによってコンテンツを動的に生成する方式)をサポートするCDNサービスプロバイダーがあります。Azureの場合、Front Door Serviceが動的サイトアクセラレーションを行います。
  • #68 プラットフォームから配信するコンテンツがスタティックなコンテンツであれば、サービスサイドの動的なコンテンツ作成を必要とることなくAzure CDNなどのContents Delivery Network(CDN)を利用することができます。【クリック】また、CDNの中には動的サイトアクセラレーション(DSA)というサービスサイドレンダリングを行う機能(サービスサイドプログラムや外部Web APIを利用したサービスサイドマッシュアップによってコンテンツを動的に生成する方式)をサポートするCDNサービスプロバイダーがあります。Azureの場合、Front Door Serviceが動的サイトアクセラレーションを行います。
  • #69 WebAssemblyはGoogleのDerek SchuffとFastlyのLuke Wagnerがチェアマンを務めるW3C WebAssembly WGが策定したブラウザで稼働するバイナリ仕様です。業務トランザクションのどの部分をブラウザ側で行い、どの部分をサービス側で行うかを柔軟に設計できます。 たとえば、映画のチケットの予約であれば自分が席を決めるまでは他の人は空いている席をどこでも予約できますが、自分が席を決めてチケットの支払いが終わるまでは、その席をロックされます。一方コンサートのチケット予約では、チケットが最後の1枚だったとしても、その支払いが終わるまでは、他の人が購入できるようにチケットのロックは行いません。サービス側にチケット売買のステータス変更を要求するタイミングが異なりますので、たとえチケット販売の業務フローが同じであってもWebAssemblyが行う業務トランザクションの範囲が異なるというわけです。 【クリック】この仕様のうち、各ブラウザがどのくらいサポートしているかを逐次レポートしてくれています。WGの[Testing]-[Web Platform browser tests]でかなり細かな機能まで確認することができます。