EC2インスタンスをRoute53 + ALB + ACMでHTTPS化独自ドメイン化して公開した手順

EC2インスタンスの立ち上げ+HTTPS化の手順

1. EC2インスタンスを作成

普通にぽちぽち作る

2. Route 53でドメイン発行

普通にぽちぽち作る

3. Certificate Managerで証明書発行

Certificate Manager＞証明書をリクエスト

より、2で作成したドメインを指定してぽちぽち作っていく。
Route 53でドメインを作っている場合、[Route 53 でレコードを作成]よりCNAMEレコードをRoute53に書き込むことができる。

4. ターゲットグループでインスタンスを指定

EC2コンソール＞ロードバランシング＞ターゲットグループ

より、[ターゲットの作成]を実施。
ロードバランサーがリクエストをどこにルーティングするかを設定する。
EC2インスタンス上のアプリケーションは3000ポートで動かしていたので、HTTPの3000ポートで設定。

5. インターネット → ロードバランサー用のセキュリティーグループを作成

EC2コンソール＞セキュリティグループ＞セキュリティグループの作成

より、ロードバランサーがインターネットに対してどのポートを受け付けるかを示すセキュリティグループを作成する。
今回はHTTPS通信のみにするので、443ポートのみ開放した。

6. ロードバランサー → アプリケーション用のセキュリティーグループを作成

EC2コンソール＞セキュリティグループ＞セキュリティグループの作成

より、アプリケーションがロードバランサーに対してどのポートを受け付けるかを示すセキュリティグループを作成する。
4で指定したポート番号を設定していないとロードバランサーがアクセスできないので注意
[ソース]欄に5で作成したセキュリティグループIDを設定することで、ロードバランサーのみアクセスを受け付けるように設定

7. HTTPS通信を受け付けるためのロードバランサーを作成

EC2コンソール＞ロードバランサー＞ロードバランサーの作成より

Application Load Balancerを作成する
[セキュリティグループ]に4で作成したセキュリティグループを指定
[リスナーとルーティング]に3で作成したターゲットグループを指定、HTTP通信の3000ポートで指定

8. EC2インスタンスにセキュリティグループを指定

EC2コンソール＞インスタンス＞インスタンス概要
より、6で作成したセキュリティグループを設定

9. 完成

「 ドメイン駆動設計を導入するためにやったこと」参加ノート

modeling-how-to-learn.connpass.com

前回に引き続き、こちらのイベントでお話を聞いてきました。自分用ノートです。

ドメイン駆動設計のプラクティスでカバーできること、できないこと

DDDの目的

1. ソフトウェアの機能性を高めること

   • 役に立つものを作る、作ったけど使えないを避ける

2. ソフトウェアの保守性を高めること

   • 機能拡張が容易でありつづけたい

アプローチ

1. ドメインエキスパートと行うドメインモデリング

   • ドメイン知識の反映とフィードバック

2. 保守性向上のためのアプローチ

   • 頻繁なモデルの更新に耐えられるパターン
     • 保守性の高いデザインパターン　エンティティ、リポジトリ

目的が明確であれば、1, 2どちらかだけでも価値がある

DDDとの相性とは

DDDはドメインが複雑な領域に適用するのに向いている

ドメインが複雑な領域とは？ドメイン把握が難しいくらいの感覚

実際のアプローチ

• https://little-hands.hatenablog.com/entry/2020/12/22/ddd-in-first-3month
• コードの作成
• レイヤーに跨るコーディング・テストの規約の整備
• ドメインモデル図を作成し、それを元に開発
• 地道なペアプロ・レビュー
• お客様の解像度をあげる
  • PdM, カスタマーサクセスと連携、フィードバックのぐるぐる
• 新機能
  • アーリーアクセス
• 既存機能
  • CSから直接お客様の声を聞く機会を設ける
• [質問] EAとGAで、機能の出しわけするのは、feature flagのような仕組みを自作しているのでしょうか？？
  • はい

すんなりいったこと

• モデル図の作成
• モデル図をもとにしたコーディング
• コーディング標準
  • お手本実装があることで、横展開しやすかった
• テスト実装
  • このレイヤーではこうしたらテストが書けるよね
• モデリング
  • diagrams.net
  • https://www.youtube.com/watch?v=A2EU0paEVJ0

巨大レガシーシステムの戦略評価とリファクタリングにおけるDDDの活用事例

問題領域と解決領域を考える

1. 娯楽を楽しみたい

   • スポーツ
   • 動画
   • ゲーム

2. 顧客を整理したい

   • CRM
   • 紙
   • Excel

モノリシックシステムは複数の問題領域にまたがりがち - 在庫・配送・注文をモノリシックなECサイトが解決するなど

問題領域が不明な場合 - 何領域があって、システムがどう関わっているか - コアドメインを見定めるのは困難

取り組んだこと

• ドメインエキスパートにインタビューを実施
  1. 解決したい課題
  2. 目的
  3. ルール、どんな世界観か
  4. 登場概念と、考え方

  →　これらの異なる境界が問題領域の境界

苦戦したこと

• 莫大な情報量
• 有識者が誰かわからない
• Rails Wayの引力
  • Active Recordに機能が集中しているのでRepositoryパターンでActive Recordを隠蔽するのが大変
• Rubyの特性
  • 動的型付け言語なのでリファクタリングが大変

基幹システムの変更を楽で安全にする

ミュータブルデータからイミュータブルデータへ

• 可能な限りUPDATEを使わない
  • INSERT, DELETE

分解思考から組み立て思考へ

• 分解して人手をわけようから、全体像を見て組み立てていこう

現場で実践してみて

ドメインモデルパターンでは規定集・業務マニュアルが設計になる

「エヴァンス本も読まずにドメイン駆動設計とは何事か？」 参加ノート

modeling-how-to-learn.connpass.com

ちょうどエヴァンス本を読んでる時にこちらのイベントを目にしたので申し込んでみました。 自分用ノートです。

イントロダクション

• 現場から学ぶモデル駆動設計 グループ
  • https://modeling-how-to-learn.connpass.com/
  • 実際に現場でやってどうだったかの肌感を共有する趣旨
  • コメント欄 ＞「ドメインエキスパート」って「現場のエキスパート」だなとつい最近気づいた。「現場で役立つシステム設計」って「ドメイン駆動設計」ですねww

エヴァンス本から今学べること

エヴァンス本から今学べること from Yukei Wachi

www.slideshare.net

• エヴァンス本をどういう本として読むか？

  • 要求は定義されている前提で、ソフトウェアでどう設計していくかという本

    • ビジネスやサービスの本ではない

  • システム設計ではなく、アプリケーション設計の本である

    • どういう構成でシステムを組むか？ではなく、アプリケーションをどう設計するか、という内容

  • DB設計や画面設計については書かれてない

    • SoRとSoE

      • 既存の業務システムはSoR（System of Record）と言われ、正確に記録することを重視して設計されます。

      • 一方、SoE（System of Engagement）とは、ユーザーとのつながりを重視して設計されるシステムを指します。

      • https://www.cyzen.cloud/magazine/soe_sor

  • 設計の本で、要件定義・テスト・運用の話はしていない

    • エンジニアとビジネスの関わり方、インタラクティブなあり方について書かれている
    • 運用設計とはまた別

  • 設計の本だけど、設計工程の本ではない

    • コメント欄＞ Evans本として選択と集中があるってことですね。なんでも含めてしまうと焦点がぼやけてしまうんですよね。

  • エヴァンスのホームページでプロセスについてちょっと書かれている

• 何が書かれているのか？

  • 考え方を示している
    • 具体的な手法を取り扱わず普遍的な考え方を示すことで、陳腐化しない
  • 考え方とは？
    • ソフトウェアに業務知識を反映させよう
      • そうすることで、柔軟に拡張したり変更したりできるようになる
      • 「反映させる」とは？
        • アプリケーションは分割と統合
          • どう部品化するか？→業務モデルに合わせて部品化していこう
      • 野球のミットがもし一枚板だったら硬いからボール取れない、軍手だと痛い
        • コメント欄＞ 第３部の導入文にでてくるはなしですね
        • コメント欄＞ リファクタリングしていくと、よく変わる部分と鉄板の部分が分かれてきて、使い込んだグローブみたいにソフトウェアがなってくよ、という感じの話ですよね。
  • どう受け止める？
    • 概念的に構造を揃えよう
      • MVCの場合、ユーザーのメンタルモデルをコンピュータモデルに持ち込む
      • どこまで業務モデルに合わせる？
        • サブシステム・パッケージ・クラス・メソッド・変数？

座談

• ファウラーのエンタープライズアーキテクチャ

• bouded contextをどう訳すかに悩んだ

  • コンテキスト境界？
  • 境界づけられたコンテキスト

• 言葉とは差でしかない

  • コメント欄＞ ソシュールですね

• 軽量DDDと言われがちですが、実装から入るのもありでは

  • Howだけでは実装できないので、実装中におのずとWhatと向き合うことになる

• POEAA?

  • エンタープライズ アプリケーションアーキテクチャパターン本

• エクリチュール

  • 本はどういうエクリチュールで書いているのかが大事

• エヴァンス本はソフトウェアエンジニアの人間賛歌

• 主役はValue Object、大きな単位で見る時はパッケージ

  • 三部四部はパッケージの話
    • 責務のレイヤーとか

• パッケージを可視化するツール

  • 意外とJIGで視覚的な図を出してみるとパッケージの依存関係が思ってたのと逆になってたりする
    • https://github.com/dddjava/jig
      • 特に値オブジェクトまで作るとなると、そういう全体像がないものが多すぎて脳がオーバーフローする

• パッケージで区別して、パッケージで認識合わせするだけでも価値がある

• サブシステム 〜 変数どこまできっちりDDDのニュアンスを適用するか？

  • サブシステム→変数のトップダウンでは、間違った状態で細部まで行ってしまうことがある
  • 小さいところから、全体をみながらビルドアップしていく方が結果的には安定しているのかも
    • コメント欄＞ 全体を正しく組むために下から組み上げる。わかる。
    • コメント欄＞ 両方向からって感じだけどな トップダウンで引けることって経験済みのことくらいしか無理だし

• しなやかな設計の章を読もう

• メイヤー本はおすすめ

  • バートランド・メイヤー

• コメント欄＞ 今までDDD本を新規メンバーに読んどいてとすると誰も完読した経験がないです。ここへの対策何かあったりしますでしょうか（苦笑

  • 1部と3部だけでいいんじゃないですか
  • 要約文を提出させるとかw
  • 太字のところ、導入部のみだけとか

自分のツイート

三部は「リファクタリング」「アナリシスパターン」「デザインパターン」たちが登場して一丸となって複雑系と立ち向かっていくのでアベンジャーズみたいで好き #エヴァンス本のススメ

— いいね (@hiyoriaya) December 16, 2021

ドメインビジョン設計文イントロにめっちゃいいなと思ったんだけど、現場だと使われてないのねw #エヴァンス本のススメ

— いいね (@hiyoriaya) December 16, 2021

ドメインと向き合うことで自分が何を提供してるかの輪郭が見えて開発体験が上がるのはありそう #エヴァンス本のススメ

— いいね (@hiyoriaya) December 16, 2021

【PhpStorm】読み取り専用でデータベースに接続する

クリティカルなデータベースにPhpStormから接続する時は、[Data Sources and Drivers] → [Options] にてRead-onlyにチェックを入れることで、読み取り専用状態でデータベースにアクセスすることができる。 その他のJetBrains製IDEでも同様かと思われる。

【Apple Silicon】Docker Desktopはこまめに更新しよう

起きたこと

Dockerコンテナ上のComposerでパッケージを追加しようとした時にCannot allocate memoryエラーが出た。

[root@8b736af411ab www]# composer require --dev squizlabs/php_codesniffer

mmap() failed: [12] Cannot allocate memory

mmap() failed: [12] Cannot allocate memory
[05-Oct-2021 13:52:53 Asia/Tokyo] PHP Fatal error:  Out of memory (allocated 52035584) (tried to allocate 147456 bytes) in phar:///usr/local/bin/composer/src/Composer/Json/JsonFile.php on line 275

Fatal error: Out of memory (allocated 52035584) (tried to allocate 147456 bytes) in phar:///usr/local/bin/composer/src/Composer/Json/JsonFile.php on line 275

答え

qiita.com

Docker Desktopのバージョンが3.3.1だったため、メモリリークの問題を抱えていた。 Docker Desktopを最新の4.1.0にしたら解決した。

[root@8b736af411ab www]# COMPOSER_MEMORY_LIMIT=-1 $(which composer) require --dev squizlabs/php_codesniffer -vvv --profile

~~~~

Package manifest generated successfully.
[836.4MiB/141.24s] Memory usage: 836.45MiB (peak: 1457.58MiB), time: 141.24s

模索した様子（全部ダメ）

memory_limitを上げてみた

[root@8b736af411ab www]# php -i | grep memory_limit
memory_limit => -1 => -1

[root@8b736af411ab www]# composer require --dev squizlabs/php_codesniffer

~~

mmap() failed: [12] Cannot allocate memory

mmap() failed: [12] Cannot allocate memory

( 'ᾥ' )ダメ

composerコマンド実行時にmemory_limit=-1を明示した

[root@8b736af411ab www]# php -d memory_limit=-1 $(which composer) require --dev --with-all-dependencies squizlabs/php_codesniffer -vvv --profile

~~

mmap() failed: [12] Cannot allocate memory

mmap() failed: [12] Cannot allocate memory

( 'ᾥ' )ダメ

[root@8b736af411ab www]# COMPOSER_MEMORY_LIMIT=-1 $(which composer) require --dev --with-all-dependencies squizlabs/php_codesniffer -vvv --profile

~~

mmap() failed: [12] Cannot allocate memory

mmap() failed: [12] Cannot allocate memory

( 'ᾥ' )ダメ

コンテナが使えるメモリ・swap領域を増やしてみた

[root@c9f8af0c1933 www]# free -m
              total        used        free      shared  buff/cache   available
Mem:          15987         773       13591         395        1622       14587
Swap:          4095           0        4095

[root@8b736af411ab www]# composer require --dev squizlabs/php_codesniffer

~~

mmap() failed: [12] Cannot allocate memory

mmap() failed: [12] Cannot allocate memory

( 'ᾥ' )ダメ

【Electron】LinuxアプリでWebカメラを複数プロセスから呼び出せない

レンダラープロセスでMediaStreamでカメラ映像を表示しつつ、メインプロセスでnode-webcam - npmを使って定期的にカメラ映像を撮影しようとしたところ、表題の問題にぶつかった。

macOS向けアプリケーションでは発生しない。

答え

video - Is it possible for two processes to access the webcam at the same time? - Ask Ubuntu

上記記事の回答にあるように、 v4l2loopbackなどで映像ソースを仮想カメラ複数にループバックさせて、レンダラープロセスとメインプロセスで使い分ける。

だめだったこと

以下のようにしてメインプロセスの定期撮影時にレンダラープロセスのMediaStreamを停止しようとしたが、Webカメラの解放までの時間が安定しなかった。

function stopStreamedVideo(videoElem) {
  let stream = videoElem.srcObject;
  let tracks = stream.getTracks();

  tracks.forEach(function(track) {
    track.stop();
  });

  videoElem.srcObject = null;
}

コード引用元：MediaStreamTrack.stop() - Web API | MDN

【Vue.js】Vue3.2でCompositionAPIで書いたコードがめっちゃ読みやすくなりそうじゃない？

blog.vuejs.org

Vue3.2がリリースされたらしい。内容がいい感じだった。

script setup

Compositon APIで書くとどうしても気になる構文の縦長さ。

<template>
  <button @click="addNum">Num:{{ num }} </div>
<template>
<script>
import { ref } from 'vue'
export default {
   setup () {
      const num = ref(10)
      const addNum = () => num.value++ 
      return { num, addNum } 
   }
}
</script>

これが

<template>
  <button @click="addNum">Num:{{ num }} </div>
<template>
<script setup>
import { ref } from 'vue'
const num = ref(10)
const addNum = () => num.value++
</script>

こうなる。超スリム。

Composition API書く時の最初のアレってどう書くんだっけ？って悩まなくてよくなりそう。
returnを書かなくてもよくなるので、バインディングが上手くいってないと思ったらreturnに書き忘れた！っていうのもなくなりそう。
気をつけないとなんでもかんでもtemplateで参照できちゃうので、そこだけ注意かも？なんか回答ありそう。

style v-bind

<script setup>
import { ref } from 'vue'

const color = ref('red')
</script>

<template>
  <button @click="color = color === 'red' ? 'green' : 'red'">
    Color is: {{ color }}
  </button>
</template>

<style scoped>
button {
  color: v-bind(color); // 👈 v-bindできる 神
}
</style>

もう見たまんま。styleでv-bindができる。神オブ神

こんなことしなくてよくなる

【Vue.js】VueCompilerに怒られずにtemplateにstyleタグを埋め込みたい - いいねのお勉強ノート

ためしたい

sfc.vuejs.org