SAMLの概要

最近ちょっと勉強したので、簡単にまとめる。

SAML を使うには、まず、idP (id provider) と SP (service provider) との間で信頼関係を構築する必要がある。具体的には以下の作業を実施する。

• idP のメタデータファイルをダウンロードする。
• idP のメタデータファイルを SP に読み込ませる。
• SP のメタデータファイルをダウンロードする。
• SP のメタデータファイルを idP に読み込ませる。

これで、idP と SP との間で信頼関係が構築される。なお、idP のメタデータファイルの中には idP の (公開鍵) 証明書の情報が入っており、これは SP にて SAML response の署名チェックに使われる。また SP のメタデータファイルの中には SP の (公開鍵) 証明書が入っており、これは idP にて SAML request の署名チェックや SAML response の暗号化に使用される。

実際の SAML の通信の流れは以下の通り。(SP 起点の方式について書く)

• ユーザ (ブラウザ) が SP にアクセスする。
• SP は認証を idP に依頼する (SAML request)。この際、ユーザのブラウザを通じて idP へリダイレクトする。
• ユーザ～idP 間で認証を行う。
• 認証 OK なら、idP から SP に SAML response を返す。この際、ユーザのブラウザを通じて SP へリダイレクトする。
• ユーザは SP へのログインできる。

ポイントは、SP と idP は直接やり取りせず、ユーザにブラウザを通じてリダイレクトでやり取りしている点。これにより、SP～idP 間の通信のことは考えなくて良いところもメリットと理解している。

分配器と分波器

テレビを買い替えてセッティングした際、本来は「分波器」を使うべきところに「分配器」を使って接続してしまったのだが、地デジも BS もちゃんと映ったので「なんで？」と思って調べたら以下の記事を見つけた。

どうしよう！分配器と分波器、間違えて買ってしまった！ | ビビッとマスプロ！みえすぎラボ

性能は落ちるようだが、分配器でも分波器の代わりができるようだ。勉強になった。

k8s のストレージ関連

最近 k8s を扱うようになって、主題の件で PV だの PVC だの出てきて混乱したので、ここに簡単にまとめる。各関係の呼び出し関係は以下の通り。

Pod -> PVC -> PV -> NFS サーバなど

Pod と NFS サーバの間に PVC と PV が挟まっているが、これは k8s 上のリソースとストレージとを疎結合にするためにこのようになっているらしい。PV は実ストレージに対応する仮想ストレージで、PVC は PV を管理するものというイメージでいるが、合っているだろうか。

Pod、PVC、PV は k8s のノード上に存在し、NFS サーバは別に存在するのが一般的だろう。

Java の enum

これまで、Java の enum の実体というかメモリ上でどうなっているかの理解が曖昧だったのだが、以下の記事を参考にさせて頂き、分かった気がする。

Javaの定数はEnumで! Enumの使い方から考え方までお伝えします

enum の各項目 (フィールド) に対応するオブジェクトが自動的に生成されている、と考えれば良さそう。自動的に生成されているので、enum の各フィールドは明示的に生成できないということなのだろう。

k8s のリソースの包含関係

忘れてしまうことが多いので、ここにメモしておく。

Namespace > Deployment > ReplicaSet > Pod > Container

最近、k8s 環境でアプリを構築したのだが、上記のうち ReplicaSet と Container はあまり意識しなかった。

k8s の最小の管理単位は Pod なので、Container を意識しないのはその通りか。ReplicaSet はもう少し踏み込んだ使い方をすると意識することになるのかな。

git で MR (Merge Request) を出してコンフリクトした時

git で MR (Merge Request) を出してコンフリクトした時、feature branch にて master に対して rebase して、feature branch に master の変更を取り込んで、コンフリクトを解消するということを以前は良くやっていた。

しばらく、git を触らなくなって、ふと「どうやっていたっけ・・？」と思ったので、簡単に試してみた。以下のようにすれば良い。

$ git init

$ touch sample.txt

★ master にて以下を実施。

$ echo "This is first commit." > sample.txt

$ cat sample.txt
This is first commit.

$ git add sample.txt

$ git commit -m "First commit."
[master (root-commit) f0f9ade] First commit.
 1 file changed, 1 insertion(+)
 create mode 100644 sample.txt

★ branch1 を作成

$ git checkout -b branch1
Switched to a new branch 'branch1'

★ また master に戻って、master のコミットを進める。

$ git checkout master
Switched to branch 'master'

$ echo "Added in master branch." >> sample.txt

$ cat sample.txt
This is first commit.
Added in master branch.

$ git add sample.txt

$ git commit -m "Added a line in master branch."
[master 8575158] Added a line in master branch.
 1 file changed, 1 insertion(+)

★ branch1 に戻りコミットを進める。

$ git checkout branch1
Switched to branch 'branch1'

$ cat sample.txt
This is first commit.

$ echo "Added in branch1." >> sample.txt

$ cat sample.txt
This is first commit.
Added in branch1.

$ git add sample.txt

$ git commit -m "Added a line in branch1."
[branch1 e8b2823] Added a line in branch1.
 1 file changed, 1 insertion(+)

★ここまでが準備。ここから本題の rebase を用いたコンフリクトの解消。
  branch1 にて master に対して rebase を実行する。

$ git rebase master
Auto-merging sample.txt
CONFLICT (content): Merge conflict in sample.txt
error: could not apply e8b2823... Added a line in branch1.
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply e8b2823... Added a line in branch1.

$ cat sample.txt
This is first commit.
<<<<<<< HEAD
Added in master branch.
=======
Added in branch1.
>>>>>>> e8b2823 (Added a line in branch1.)

★以下で sample.txt を編集してコンフリクトを解消。

$ vi sample.txt

$ cat sample.txt
This is first commit.
Added in master branch.
Added in branch1.

$ git add sample.txt

$ git rebase --continue
[detached HEAD 697c015] Added a line in branch1.
 1 file changed, 1 insertion(+)
Successfully rebased and updated refs/heads/branch1.

$ git status
On branch branch1
nothing to commit, working tree clean

$ git log
commit 697c015003f2e61507a00c3d37769833e50e0ff3 (HEAD -> branch1)
Author: xxxxx <you@example.com>
Date:   Sun Nov 19 16:38:57 2023 +0900

    Added a line in branch1.

commit 857515894d3f4e5b3a0bc90b4c38da23bd2517e4 (master)
Author: xxxxx <you@example.com>
Date:   Sun Nov 19 16:37:16 2023 +0900

    Added a line in master branch.

commit f0f9adebf3ffc3c5b4ade40069c79d353a108206
Author: xxxxx <you@example.com>
Date:   Sun Nov 19 16:34:42 2023 +0900

    First commit.

★以上で rebase を用いたコンフリクトの解消が完了。
  master に branch1 を繋げるかたちなので、First commit -> master での変更 -> branch1 での変更 という順になっている。

以下の記事を参考にさせて頂きましたm(_ _)m

【初心者向け】git rebaseの基本

【Git】コンフリクトが起きたらrebaseで解決！ - 小さなことからこつこつと。

同じ文字でグルーピング

leetCode の以下の問題を解いた。
https://leetcode.com/problems/string-compression/

文字列中の連続する同じ文字をグルーピングするという問題。
こういうのは、これまで、文字列を前から見て行って、同じ文字の連続が途切れたら、その１つ前までを１グループとして纏める、といった感じで処理を書いていた。

しかし、解説を読んだところ、two pointers 的な考えを使って書くと、よりシンプルに書けることが分かった。以下のような感じ。

public class StringCompression {
    public int compress(char[] chars) {
        int start = 0;
        int curPos = 0;
        while (start < chars.length) {
            int end = start;
            while (end < chars.length && chars[end] == chars[start]) {
                end++;
            }
            // ここを抜けてきた時の end は、例えば、aaaaaa[b]bb の [b] を指している。
            // つまり、end の一つ前までが同じ a グループとなる。

            int groupLen = end - start;
            chars[curPos++] = chars[start];
            if (groupLen > 1) {
                for (char ch : Integer.toString(groupLen).toCharArray()) {
                    chars[curPos++] = ch;
                }
            }
            start = end;
        }
        return curPos;
    }
}

グループの start を一旦固定して、そこから end を行けるところまで後方に動かしていく感じ。こうすると、場合分けとかも少なくシンプルに実装できる。