feat(b0): B-0 을 주입부터 원상복구까지 끝까지 밟는다 — setup 35편 완주
남아 있던 한 편이다. keycloak-pattern 에 이 실험과 무관한 변경이 39개(미추적 3개 더) 있어 따로 떼어낸 작업 트리에서 파일 넷을 고치고 이미지를 구워 두 노드에 넣었다. 원래 작업 트리는 한 글자도 안 바뀌었다. 자동구성이 고른 것 - 빈 321개 — 이 편이 예측한 숫자와 같다 - authorizedClientService -> InMemoryOAuth2AuthorizedClientService - SessionRepository 빈이 하나도 없다. Spring Session 이 아예 안 걸렸고 세션을 톰캣이 자기 메모리의 HttpSession 에 직접 들고 있다 - 타입에 Redis 나 Jdbc 가 든 빈 0개 로그인이 replica 개수에서 갈린다 - 원 가이드는 브라우저로 한 번 해 보라고 적는데 그러면 한 번의 결과만 남는다. 쿠키 병을 쓰는 curl 로 같은 흐름을 여섯 번씩 돌려 양쪽을 같은 수로 견줬다 - replica 2 — 여섯 번 다 /login?error - replica 1 — 여섯 번 다 200. 이쪽이 대조군이라, 거기서도 실패했으면 가설이 아니라 시험 방법을 의심해야 한다 - 토큰 경계는 원래 실행과 한 글자도 다르지 않았다 원상복구를 같은 명령으로 확인했다 - 빈 321 → 437, InMemory → Jdbc, Redis/Jdbc 빈 0 → 58, Redis 세션 키 6 - replica 2 에서 로그인이 다시 되는 것이 복구 판정이다 그리고 ⑤ 의 `git diff --stat` 점검은 작업 트리가 깨끗할 때만 성립한다는 것을 적었다. git worktree 로 떼어내면 그 점검이 다시 살아난다. 관문: check_body PASS · check_prose error 0 · check_evidence 문제 없음 · verify-tech-log-tree error 0 · verify-project-layout error 0 · 코드펜스 전수 0건 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
DongHyeonka
co-authored by
Claude Opus 5
Claude Opus 5
parent
bbd87dc9ab
commit
7661f08d58
@@ -7,7 +7,7 @@
|
||||
"revision": "9465582b5d1630eb4ae7c4e078021486919bf6b6",
|
||||
"verified": "반입할 때 적어 둔 source/.source-revision 이 이 커밋이고 저장소에 실재한다 — 「chore: 실행 환경 구성 문서 추가 및 수정」, 2026-09-10. **전에 이 칸은 cdac9b81 이었고 그것은 틀렸다** (2026-09-17 대조) — 그 커밋은 2026-09-04 이고 반입본 306개 가운데 docs/guides/** 28개가 거기에 아예 없다. 가이드는 그 엿새 뒤 6f6ab86 에서 들어왔다. **그런데 반입한 바이트는 이 커밋과도 같지 않다** — 9465582b 와 같은 것은 276개이고 29개가 다르다. 같은 306개를 저장소의 **작업 트리**와 견주면 297개가 같다. HEAD 에서 200 커밋을 거슬러 전수 대조했을 때 가장 가까운 6f6ab86 도 28개가 어긋났다. **맞는 커밋은 없다** — 반입은 커밋이 아니라 **그 시점의 작업 트리**(미커밋 수정이 있던 상태)에서 떠 온 것이다. 지금도 저장소는 그 파일들을 M 으로 낸다. 작업 트리와 남은 차이 8개 가운데 5개가 그 M 목록에 있고(반입 뒤 저장소가 더 고쳤다), deploy/lab/host/nginx-keycloak-lab.conf 는 저장소에서 deploy/lab/edge/ 로 옮겨져 반입본에만 남았다. **이 커밋은 「반입 시점의 HEAD」라는 뜻이지 「반입한 바이트가 이것이다」가 아니다**"
|
||||
},
|
||||
"ssotSha256": "2ef1b420217e7a949917f13c6ffcb672516433b99d53dfd761f4f1f662653e55",
|
||||
"ssotSha256": "02d7dcfb862178b4b0a49453bf8ef0693226d7ab52ca44d695d9b988b471c265",
|
||||
"sourceRevision": "keycloak-session-lab@2026-09",
|
||||
"generatedAt": "2026-09-17",
|
||||
"candidateScope": {
|
||||
|
||||
+60
-10
@@ -825,13 +825,11 @@ authorization-uri: ${KC_ISSUER_EXTERNAL}/protocol/openid-connect/auth
|
||||
authorization-uri: ${KC_ISSUER_EXTERNAL:http://localhost:8080/realms/keycloak-patterns}/protocol/openid-connect/auth
|
||||
```
|
||||
|
||||
## 이 실험대에서 어디까지 밟았나
|
||||
## 2026-09-17 에 끝까지 다시 밟았다
|
||||
|
||||
2026-09-17 에 기반 가이드로 실험대를 새로 세우고 이 편을 어디까지 밟고 멈쮘는지 적는다. **못 밟은 것을 밟은 것처럼 적지 않으려고 남긴다.**
|
||||
기반 가이드로 실험대를 새로 세우고 이 편을 주입부터 원상복구까지 다시 밟았다(observed). 아래는 그날의 값이다.
|
||||
|
||||
**주입 1 절(파일 넷 편집)과 2 절의 빌드까지 밟았다**(observed). 두 노드에 이미지를 밀어 넣는 데부터는 안 밟았다.
|
||||
|
||||
**★ ⑤ 의 `git diff --stat` 점검은 작업 트리가 깨끗할 때만 성립한다**(2026-09-17, observed). 그 줄은 「네 파일만 나오는가」로 덜 지운 것을 잡으려는 것인데, `keycloak-pattern` 에 이 실험과 무관한 변경이 39개 있어(미추적 3개 더) 그 점검이 무의미해졌다. 따로 떼어낸 작업 트리에서 고치면 그 점검이 다시 살아난다.
|
||||
**★ ⑤ 의 `git diff --stat` 점검은 작업 트리가 깨끗할 때만 성립한다**(2026-09-17, observed). 그 줄은 「네 파일만 나오는가」로 덜 지운 것을 잡으려는 것인데, `keycloak-pattern` 에 이 실험과 무관한 변경이 39개 있어(미추적 3개 더) 그 점검이 무의미해졌다. 따로 떼어낸 작업 트리에서 고치면 점검이 다시 살아난다.
|
||||
|
||||
```bash label="[워크스테이션] 다른 작업이 섞여 있을 때"
|
||||
git worktree add --detach /tmp/kp-b0 HEAD
|
||||
@@ -841,7 +839,7 @@ git worktree add --detach /tmp/kp-b0 HEAD
|
||||
|
||||
**넷을 다 뺀 뒤에 무엇이 남는지를 숫자로 확인했다**(observed). `pom.xml` 은 XML 로 유효하고 starter 셋(actuator · oauth2-client · web)과 시험 의존 둘만 남는다. `SecurityConfig.java` 에는 `bffSecurity` 하나만 남고 import 일곱이 같이 빠진다. `application.yml` 의 `spring` 아래는 `application` 과 `security` 둘뿐이고, `server.servlet.session` 은 손대지 않는다 — 그것은 쿠키 이름 설정이라 저장소 선택과 무관하다. 매니페스트에서는 env 여섯만 빠지고 Redis Deployment · Service · PVC 는 남는다.
|
||||
|
||||
**빌드는 한 번에 통과했다**(observed). 이 편이 앞에 적어 둔 `processDuplicateKeys` 빌드 실패는 다시 나오지 않았다.
|
||||
**빌드는 한 번에 통과했다**(observed). 이 편이 앞에 적은 `processDuplicateKeys` 빌드 실패는 다시 나오지 않았다.
|
||||
|
||||
```text label="docker build 의 끝"
|
||||
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0
|
||||
@@ -849,13 +847,65 @@ naming to docker.io/library/keycloak-pattern-bff:lab done
|
||||
exit=0
|
||||
```
|
||||
|
||||
**안 밟은 것** — `k3s ctr images import` 로 두 노드에 넣는 단계부터다(unknown). 따라서 3 절 배포, 주입 검증, 관찰 3·4 절, 복구 절은 이번에도 원래 실행의 값이다.
|
||||
### 자동구성이 고른 것
|
||||
|
||||
**그래서 지금 실험대의 BFF 는 여전히 B-1·B-2 상태다**(observed). 빈 목록에 `RedisSessionRepository` · `RedisHttpSessionConfiguration` · `JdbcOAuth2AuthorizedClientService` 가 다 있다. 이 상태에서 replica 2 로 로그인하면 **성공한다** — B-0 은 같은 조건에서 실패한다고 적는다. 두 편을 가르는 것이 세션 저장소 하나임을 반대편에서 확인한 셈이다.
|
||||
**빈이 321개다**(observed) — 이 편이 예측한 숫자와 같다. 그리고 **`SessionRepository` 빈이 하나도 없다.**
|
||||
|
||||
**밟은 관찰** — 관찰 1·2(파드 안에서 빈 목록 받기, 저장소 계열 빈 뽑기)와 5 절의 토큰 경계. `bff/token-boundary` 가 `accessTokenStoredOnServer=true` · `refreshTokenStoredOnServer=true` · `browserTokenCount=0` 을 내는 것은 이 상태에서도 같다(observed).
|
||||
```text label="[lab host] 빈 목록에서 뽑은 것"
|
||||
빈 개수: 321
|
||||
authorizedClientService -> org.springframework.security.oauth2.client.InMemoryOAuth2AuthorizedClientService
|
||||
OAuth2AuthorizedClientManager -> org.springframework.security.oauth2.client.web.DefaultOAuth2AuthorizedClientManager
|
||||
authorizedClientRepository -> org.springframework.security.oauth2.client.web.AuthenticatedPrincipalOAuth2AuthorizedClientRepository
|
||||
SessionRepository 계열 -> 없다
|
||||
타입에 Redis 나 Jdbc 가 든 빈 -> 없다
|
||||
```
|
||||
|
||||
`SessionRepository` 가 없다는 것은 Spring Session 이 아예 안 걸렸다는 뜻이고, 그러면 세션을 톰캣이 자기 메모리의 `HttpSession` 에 직접 들고 있다. 토큰 쪽도 `InMemory…` 다. **둘 다 프로세스 메모리에 있고, 아무것도 설정하지 않으면 이렇게 된다.**
|
||||
|
||||
### 로그인은 replica 개수에서 갈린다
|
||||
|
||||
원 가이드는 브라우저로 한 번 로그인해 보라고 적는데, 그러면 한 번의 결과만 남는다. 쿠키 병을 쓰는 `curl` 로 같은 흐름을 여섯 번씩 돌려 양쪽을 같은 수로 견켜 봤다(observed).
|
||||
|
||||
```text label="replica 2 — 여섯 번 다 실패"
|
||||
1 https://app1.hyeonworks.com/login?error 200
|
||||
2 https://app1.hyeonworks.com/login?error 200
|
||||
3 https://app1.hyeonworks.com/login?error 200
|
||||
4 https://app1.hyeonworks.com/login?error 200
|
||||
5 https://app1.hyeonworks.com/login?error 200
|
||||
6 https://app1.hyeonworks.com/login?error 200
|
||||
```
|
||||
|
||||
```text label="replica 1 — 여섯 번 다 성공"
|
||||
1 https://app1.hyeonworks.com/ 200
|
||||
2 https://app1.hyeonworks.com/ 200
|
||||
3 https://app1.hyeonworks.com/ 200
|
||||
4 https://app1.hyeonworks.com/ 200
|
||||
5 https://app1.hyeonworks.com/ 200
|
||||
6 https://app1.hyeonworks.com/ 200
|
||||
```
|
||||
|
||||
**여섯 대 여섯으로 갈리니 가설이 확정된다.** 한 번만 치면 replica 2 에서 우연히 같은 파드로 가 성공할 수도 있고, 그러면 반대로 읽힌다. 그리고 replica 1 쪽이 대조군이다 — 거기서도 실패했으면 가설이 아니라 시험 방법이 틀린 것이다.
|
||||
|
||||
토큰 경계는 원래 실행과 한 글자도 다르지 않았다(observed).
|
||||
|
||||
```text label="replica 1 에서 로그인한 뒤 /bff/token-boundary"
|
||||
{"pattern":"AP3-backend-for-frontend","principal":"labuser","accessTokenStoredOnServer":true,"refreshTokenStoredOnServer":true,"browserTokenCount":0,"csrfProtectionEnabled":true}
|
||||
```
|
||||
|
||||
### 원상복구를 같은 명령으로 확인했다
|
||||
|
||||
replica 를 2 로 되돌리고 예전 이미지를 두 노드에 다시 넣고 원래 매니페스트를 다시 올렸다. 돌아왔는지는 같은 빈 목록과 같은 로그인 시험으로 봤다.
|
||||
|
||||
| 재본 값 | B-0 | 복구 뒤 |
|
||||
|---|---|---|
|
||||
| 빈 개수 | `321` | `437` |
|
||||
| `authorizedClientService` | `InMemoryOAuth2AuthorizedClientService` | `JdbcOAuth2AuthorizedClientService` |
|
||||
| 타입에 Redis 나 Jdbc 가 든 빈 | `0` | `58` |
|
||||
| replica 2 로그인 6회 | 6번 다 `/login?error` | 6번 다 `200` |
|
||||
| Redis 세션 키 | — | `6` |
|
||||
|
||||
**replica 2 에서 다시 로그인이 되는 것이 복구 판정이다.** 그것이 되면 세션이 다시 Redis 를 타고 있다는 뜻이다.
|
||||
|
||||
**앞서 적어 둔 「남은 것은 인증서 하나」는 해결됐다**(2026-09-17, observed). 호스트에 있던 인증서를 엣지 게스트로 옮기고 강제 갱신까지 치면서 `https://auth.hyeonworks.com` 은 선다. 지금 남은 걸림돌은 소스 쪽 하나다.
|
||||
|
||||
## 무엇이 관측이고 무엇이 아닌가
|
||||
|
||||
|
||||
Reference in New Issue
Block a user