【WSL】Docker環境構築メモ

WSLでのDocker開発環境構築のメモ

WSLのセットアップ

wsl --install

docs.microsoft.com

.wslconfigにメモリ使用量設定

[wsl2]
memory=1GB
swap=0

WSLにDockerをインストール

Docker

docs.docker.com

Compose V2 docs.docker.com

make install

sudo apt install make
sudo apt install make-guile

WSLシェルのルートディレクトリを/home/****に変更

mseeeen.msen.jp

GitHubsshのconfig

Host github.com
  IdentityFile ~/.ssh/鍵ファイルの名前
  User git

WSLの公開ポートへのアクセス

localhostにアクセスするとWSLのIPへルーティングしてくれる

https://localhost:3000/

みたいにアクセス

【Laravel】FROM句にサブクエリを入れて集計したい

type total subtotal
1 10 0
1 0 20
2 100 0
2 0 200

LaravelでUNION ALLしたこういう結果表を集計したいときは以下のように書く。

DB::table(DB::raw('(' . $subQuery->toSql() .') AS s1'))
    ->mergeBindings($subQuery)
    ->selectRaw(
    'SUM(s1.total) + SUM(s1.subtotal)'
)
->groupBy(['s1.type'])
->get();

【Docker】apt-getで The following signatures couldn't be verified because the public key is not available: NO_PUBKEY エラー

mysql 5.7 imageでのapt-get updateがなんか失敗するようになった。

 ERROR [2/2] RUN apt-key update &&     apt-get update &&     apt-get install -y locales &&     rm -rf /var/lib/apt/lists/* &&     echo "ja_JP.UTF-8 UTF-8" > /etc  14.2s
------

~~~

#5 14.16 W: GPG error: http://repo.mysql.com/apt/debian buster InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY << pubkey >>

pubkeyが登録されていないらしいので、する。

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys << pubkey >>

【Rails】EC2インスタンスがRailsのWebpacker周りでフリーズする

rails webpacker:installとかrails assets:precompile RAILS_ENV=productionとかしたらよくコンパイルの途中にEC2インスタンスがフリーズする。
開発環境やステージング環境でt2.smallなどを選択すると頻発するので注意。

なってしまったら諦めてEC2コンソールからインスタンスの停止→開始をする必要がある

アセットコンパイルはローカルで行ってEC2インスタンスにpushするとかを検討したほうがいいかもしれない。

qiita.com

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

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

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

普通にぽちぽち作る

2. Route 53でドメイン発行

普通にぽちぽち作る

3. Certificate Managerで証明書発行

f:id:iine_programming:20220124112739p:plain

Certificate Manager>証明書をリクエス

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

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

f:id:iine_programming:20220124102205p:plain

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

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

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

f:id:iine_programming:20220124101634p:plain

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

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

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

f:id:iine_programming:20220124101939p:plain

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

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

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

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

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

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

f:id:iine_programming:20220124113820p:plain

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

9. 完成

f:id:iine_programming:20220124113608p:plain

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

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のような仕組みを自作しているのでしょうか??
    • はい

すんなりいったこと

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

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

  1. 娯楽を楽しみたい

    • スポーツ
    • 動画
    • ゲーム
  2. 顧客を整理したい

モノリシックシステムは複数の問題領域にまたがりがち - 在庫・配送・注文をモノリシックな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

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

www.slideshare.net

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

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

      • ビジネスやサービスの本ではない
    • システム設計ではなく、アプリケーション設計の本である

      • どういう構成でシステムを組むか?ではなく、アプリケーションをどう設計するか、という内容
    • DB設計や画面設計については書かれてない

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

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

        • https://www.cyzen.cloud/magazine/soe_sor
    • 設計の本で、要件定義・テスト・運用の話はしていない

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

      • コメント欄> Evans本として選択と集中があるってことですね。なんでも含めてしまうと焦点がぼやけてしまうんですよね。
    • エヴァンスのホームページでプロセスについてちょっと書かれている

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

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

座談

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

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

    • コンテキスト境界?
    • 境界づけられたコンテキスト
  • 言葉とは差でしかない

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

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

  • エクリチュール

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

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

    • 三部四部はパッケージの話
      • 責務のレイヤーとか
  • パッケージを可視化するツール

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

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

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

  • メイヤー本はおすすめ

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

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

自分のツイート