Hejdaの見る夢

一人前のエンジニアを目指して頑張ったこととかをつらつら書くブログ

2023 年振り返り プライベート編

概要

2023 年のアウトプットの振り返りは別のポストでしたので、そこでは省いたプライベートの話など

育児

ほぼこれ。去年の年末に娘が生まれて、あたふたと育児してたらもう 1 年経ってた感じ。

結婚する前は結婚するなんて考えられなかったし、子供が産まれる前までは育児はどこか他人事だったけど、今では大切なもののひとつになっている。人って変わるんだなぁと常々思っている。というか、思わされてる。

来年は家族旅行出来るといいね

本当に感謝してる。特に今年はたくさん育児イベントを企画してくれて、僕も育児に参画するきっかけを作ってくれてるのでとても楽しい思い出を作れてる。平日も娘を積極的に色んなとこに連れて行ってくれてるので、娘にとっても良い経験になっていればいいね。その分、土日は休めるように、僕が娘を連れて散歩でも行ってきますね

妻がパートナーで良かったと改めて思った 1 年でした

家族が増えるので思い切って分譲マンション買った。人生初の 4 桁万円のローン組んだけど、あまり違和感無いのすごいよね(慣れてるという意味ではなく、実感が無いという意味) 戸建ても考えたけど、家のメンテとかご近所付き合いとかの考えなくてはいけない変数を増やすの辛いのでマンションで良かったなと。あと、24 時間何時でもゴミを集積所に出せるシステムなのが非常に助かってる

ローン頑張って返していこう

仕事

現職の仕事では良い上司に恵まれて自由にやらせて貰ってるので仕事内容についてはあまり不満は無い。けど、それ以外ではあまり長居は出来ないなぁと感じることが多くなった 1 年でもある

適切な距離を見極めていきたい

副業

有難いことに 2 社でお仕事頂いている。ただ、今年はあまり稼働出来てないし、実績もあまり残せていないので奮起しないといけないと思ってる。単純に時間確保の問題なので効率化して時間捻出していかないと。

時間が無いと言い訳しない(ように頑張る)

ユーザコミュニティ

来年はどんどん参加してアウトプットを残して行きたい。まずは今 1 番興味のあるサーバレス系及びデータベース系。

技術を楽しんでいこう(๑•̀ㅂ•́)و✧

まとめ

ここまでつらつらとお風呂の中で書いてる。これくらいの温度感で1年のまとめは書いていきたい

さて、汗と涙とヨダレでくたくたな娘の 1 番のお気に入りぬいぐるみを洗おうかな😎

(ちょっと早いけど) 今年のアウトプットを振り返る 2023

概要

個人的な今年の振り返りをアウトプット中心に見ていきます

イベントなどのリアル参加

ブログなど

note (育児ネタ)

1 回だけ書いた...

note.com

はてなブログ (調査したことや時間によって変わりそうなこと内容が中心)

2024 年は 4 投稿でした

iganari.hatenablog.com

iganari.hatenablog.com

iganari.hatenablog.com

iganari.hatenablog.com

Zenn (ある程度時間が経っても情報が変わらなそうなことが中心)

2024 年は 1 投稿でした

zenn.dev

しずかなインターネット (雑記)

11 月後半から始めました

探さないでください... (マジで)

コードコミット

一概には言えないけど Public 系のものはアウトプットと言ってもいいのでは。と思っています... が、今年に新規作成したものとアップデートしたものの区別がめんどくさい難しいので Contributions の草状況を見ていきます

github.com

GitHub | Contributions の草状況 2023

GitLab | Contributions の草状況 2023

所感

家族が増えて自分の時間を自分のためだけに使える割合が圧倒的に減ったことにより、勉強会の開催やリアル参加・記事の執筆などが減っていることが分かり、そういうことに自分の時間を使っていたのだなと改めて認識しました :)

時間の使い方を今まで以上に効率化していかないとな。と思いつつ、ライフステージが変わったことをポジティブに捉え、このステージで出来ることを精一杯満喫していきたいと思います

Have Fan!! :)

ハンズオン資料を作ったので軽く解説を書く (Hands On Cloud Run to Memorystore for Redis)

概要

以下の自作のハンズオン資料の解説記事です :)

github.com

ハンズオンでやっていること

主に以下の 2 点を実際に構築出来ます

1. 同じプロジェクト内で Cloud Run から Memorystore にアクセスする

https://raw.githubusercontent.com/iganari/handson-run-memorystore-redis/main/single-project/direct-peering/_img/dp-overview.png

2. 違うプロジェクトの Cloud Run から Memorystore にアクセスする

https://raw.githubusercontent.com/iganari/handson-run-memorystore-redis/main/different-projects/_img/diffproject-overview.png

使っているサービスのおさらい

Cloud Run

Google Cloud のコンテナを直接実行できるフルマネージドサービスです

cloud.google.com

Memorystore

Google Cloud のフルマネージドのインメモリデータベースのサービスです

Redis, Redis Cluster, Memcached の中から選べます (2023/12 現在)

今回は Memorystore for Redis を利用しています

cloud.google.com

Direct VPC egress

Cloud Run から (Google Cloud の) VPC Network に紐づくサービスに内部通信出来るようになるサービスです

2023/12 現在では、まだ Preview の機能です

みんなが待ち望んでいた機能なので、すでに知っている人も少なく無いと思います ;)

cloud.google.com

Direct peering

ユーザ管理の VPC Network と Google 管理のプロジェクトの VPC ネットワークを VPC Peering する機能です

Memorystore for Redis は Google 管理のネットワークにあるリソースのため、この Peereing が必要になります

後述の Private services access とどちらかを使用する必要があります

cloud.google.com

Private services access

ユーザ管理の VPC Network と Google サービス ネットワークの間にピアリングを作成する機能です

cloud.google.com

Shared VPC

複数の Google Cloud プロジェクトにて、 1 つの VPC Network を共有する機能です

Google Cloud の組織を導入することで利用できる機能の一つです

cloud.google.com

Redis Commander

Web ブラウザ上で Redis を操作できるアプリケーションです

下記からお借りしています :)

Special Thanks!!

github.com

苦労した点

違うプロジェクトの Cloud Run から Memorystore にアクセスする際の Role の考え方

以下の構成を取るのですが、これを理解するのに時間が掛かりました...

  1. 共有 VPC を使っていて、ホストプロジェクトに Memorystore があり、サービスプロジェクトに Cloud Run が設置してある
  2. Cloud Run が動いているプロジェクトのデフォルトの Cloud Run 用の Service Account に、 Memorystore が動いているプロジェクトのネットワークの Role を付与する
  3. Cloud Run のサービスに付与した Service Account を、デフォルトの Cloud Run 用の Service Account を使用出来るようにする

https://raw.githubusercontent.com/iganari/handson-run-memorystore-redis/main/different-projects/_img/diffproject-02-02.png

最初は Cloud Run のサービスに付与した Service Account に、Memorystore が動いているプロジェクトのネットワークの Role を付与すれば OK だろうと思っていたのですが、それだと動きませんでした :(

最後に

ここまで読んで気になった方は、ぜひハンズオンをやってみてください ;)

Have Fan!! :)

HSTS で詰まったのと一時的な解決策を見つけた話

概要

若手の構築課題を作っている最中に、 HTTP Strict Transport Security (HSTS) の強制適用により http://{ドメイン} が Web ブラウザで表示出来ない( https にリダイレクトしてしまう )問題に出会いました

最終的には https://{ドメイン} にするけど、その過程でどうしても http://{ドメイン} を Web ブラウザで表示したかったので自分なりに回避策を調べました

HSTS とは

RFC 6797 で定義される、Web サイトが Web ブラウザに HTTPS でのアクセスを指示することで中間者攻撃を防止するための技術で、要は HTTP でアクセスしようとしても Web ブラウザ側で強制的に HTTPS に変換してしまうものです

参考: JPRS用語辞典|HSTS(エイチエスティーエス、Hypertext Strict Transport Security)

現在の主要な Web ブラウザ (Chrome, Firefox, Opera, Safari, IE 11 and Edge) は対応しています

参考: HSTS Preload List Submission

HSTS の回避方法

Web ブラウザの設定で回避する設定をすることが出来ます

例えば、 Google Chrome の場合は

  1. chrome://net-internals/#hsts にアクセス
  2. Delete domain security policies に HSTS を除外したいドメインを入れる
  3. Delete を実行

で、出来るとのことです

参考: httpで表示したいサイトがhttpsにリダイレクトされ、サイトが表示できない - Google Chrome Community

ただし、今回はこれでもダメな場合の話です\(^o^)/

HSTS は全てのドメインに適用されているわけでは無い

そもそもの話ですが、 HSTS はすべてのドメインで適用になっている訳ではないので、まだ HSTS が強制適用されていないドメインを使えば HSTS を回避出来ます

  • 2023/11 時点ですでに強制適用されているドメイン
    • appdev
  • 2023/11 時点では HSTS が強制適用されていないドメイン
    • jporg

つまり、 hogehoge.jp とか fizzbuzz.org などのドメインならまだドメインを HTTP で運用可能です

fizzbuzz.org などは、お名前ドットコムで1年間1000円くらいから購入出来るので比較的にリーズナブルに運用が可能です

ただし、これは 2023/11 時点の話であり、いつ上記のドメインの HSTS が強制適用になるかは不明です

HSTS が強制適用されるか確認できるサイト

以下のサイトで自分で調べることが出来ます

hstspreload.org

HSTS が強制適用される場合

https://hstspreload.org/?domain=app

HSTS が強制適用されない場合

https://hstspreload.org/?domain=jp

まとめ

HSTS 自体はセキュリティを高めるための必須な仕様なので、それに準じた構築を心がけましょう :)

とはいえ、例外的に HTTP を使いたい時はあるので、HSTS 回避はあくまで一時的なものとしたほうがいいと思います ;)