본문 바로가기

전체 글80

내가 만든 이미지 tar 는 무슨 포맷일까? docker, podman, skopeo 를 직접 돌려보며 정리한 노트 CKAD를 살며시 준비하다가 "이미지를 OCI 또는 Docker 포맷으로 저장하라" 는 한 줄에서 멈칫했다. docker save 는 수없이 쳐봤는데, 그 결과물이 어느 포맷인지 설명하라고 하면 말이 막혔다. 그래서 세 도구를 로컬에서 직접 돌려 tar 를 하나씩 까봤고, 그 과정에서 예상과 다른 결과를 세 번 만났다. 이 글은 그 실험 기록과, 이후 실무에서 꺼내 쓰려고 모아둔 명령어 노트다.Introdocker 는 상주 데몬 위에서 빌드, 실행, 전송, 네트워크, 볼륨까지 다 하는 올인원 도구다. podman 은 거의 같은 CLI 를 데몬 없이 사용자 권한으로 돌린다. skopeo 는 이미지를 실행하지 않고 옮기고 변환만 한다.포맷은 도구 이름이 아니라 tar 안의 파일로 판단한다. oci-layou.. 2026. 10. 12.
함께 자라기에 나도 포함하기 얼마 전, 좋은 동료와 좋은 어른이 되고 싶다는 회고를 썼다. 팀에 마음을 쓰고 사람들과 함께 자라는 일이 왜 내게 중요한지 정리한 글이었다. 그런데 쓰고 나서야 돌아보게 됐다. 그동안 나는 정작 나 자신을 얼마나 돌봤을까.지난 금요일부터 주말까지 많이 힘들었다. 솔직히 나도 모르게 번아웃이 온 것 같았다. 내가 더 뛰어야지, 내가 다 알고 있어야지. 애써 마음 쓴 프로젝트가 잘못되는 걸 보기 힘들어서, 괜찮은 척 웃으면서 계속 달렸다. 믿고 의지할 사람들이 생겼는데도 혼자 책임지던 습관은 그대로였다. 솔직히 혼자 해결할 때의 쾌감도 있었다.금요일 퇴근 전, 라이언과 단둘이 이야기하다 처음으로 울었다. 갑자기 눈물이 나서 두서없이 말을 꺼냈는데, 오래전부터 혼자 얼마나 고생했을지 말하지 않아도 느껴진다고.. 2026. 10. 5.
좋은 어른이 되어간다는 것 요즘 팀에 이런저런 이슈가 많았다. 나는 나대로 고민이 많았고, 그 고민을 한 번은 글로 정리해두고 싶었다. 거창한 리더십 이야기는 아니다. 감투도 없는 내가 왜 자꾸 팀의 일에 마음을 쓰는지, 그게 과한 건 아닌지에 대한 생각 정리에 가깝다.시 한 편에서 시작한 생각자신 안에 자리한 악의 능력을끊임없이 상기시키는 자가 있다자신 안에 커오는 선의 능력을쉬임 없이 고무시키는 자가 있다그는 어느 쪽인가나는 어느 쪽인가악은 선을 삼켜야만 연명할 수 있으니선은 악에 맞서야만 커나갈 수 있으니그러니 선한 이여악에게 자신을 내어주지 마라위선을 떨치고 선함을 지켜라진실로 선한 사람은 나쁜 사회에서도자기 영혼을 잃지 않고 좋은 삶을 사는 사람아무리 작아도 선한 존재는그 자체로 어두운 세상의 등불이니아무리 무력한 듯해도.. 2026. 10. 1.
앱은 살아 있는데 서비스 간 호출만 401: OpenBao 가 발급하는 서비스 신원 JWT 를 따라가 보니 앞 글에서는 사람과 ESO 가 OpenBao 에 들어오는 문(인증)과 들어와서 닿는 범위(정책)를 봤다. 팀 책임님과 공통 인증 게이트웨이와 공통 프레임워크를 설계하면서 가장 오래 붙잡은 질문은 따로 있었다. "서비스가 서비스를 부를 때 무엇으로 자기를 증명하나." 사람 로그인은 Keycloak JWT 를 게이트웨이에서 검증하면 됐지만, 서비스 간 호출에는 별도의 신원이 필요했다. 우리는 그 신원 JWT 를 OpenBao 가 발급하게 하고, 받는 쪽은 공통 프레임워크의 Resource Server 설정으로 검증하게 했다. 그 JWT 한 장이 만들어지기까지 AppRole, Identity, Agent 가 차례로 등장한다. 이 글은 함께 설계한 그 길을 다시 따라가며, 적용하고 나서 보인 빈틈까지 적는다.함.. 2026. 9. 27.
시크릿을 KV 에 넣었다고 끝이 아니었다: OpenBao 의 경계는 인증과 정책이 정한다 기존 프로젝트에서 OpenBao 는 나한테 "KV v2 에 값을 넣고 읽는 곳" 이었다. 토큰 하나를 설정 파일에 두고 HTTP 로 부르면 끝이었다. 팀을 옮기고 팀 내 책임님과 함께 여러 제품이 같이 쓰는 공통 인증 게이트웨이와 백엔드 공통 프레임워크를 만들게 됐다. 제품마다 시크릿을 같은 방식으로 받아 가고, 서비스 간 호출에서 "누가 보냈는가" 를 같은 규칙으로 증명하려면 그 밑단에 공용 OpenBao 를 두어야 했다. 그래서 KV 말고도 인증 방식과 제품별 정책, AppRole 과 Agent 까지 책임님과 같이 설계하고 bootstrap 스크립트로 적용했다. 적용한 뒤에는 설계대로 올라갔는지 kubectl 과 스크립트를 한 줄씩 다시 읽으며 점검했고, 그때 멈칫한 곳도 함께 적는다. 이 글은 그중.. 2026. 9. 27.
Helm 뜯어보기 3: values 파일 하나로 버티던 배포 저장소를 base/overlay 로 옮긴 이유 두 개의 배포 저장소를 연달아 다뤘다. 앞의 것은 서비스마다 Helm 차트가 있고 환경마다 values 파일이 하나씩 있는, 가장 흔한 구조였다. 뒤의 것은 같은 Helm 차트를 Kustomize 로 감싸 base 와 overlay 로 조립한다. 둘 다 "Helm 으로 배포한다" 고 말하지만 값을 어디에 두는지, 이미지 태그를 누가 어디에 쓰는지, 시크릿을 어떻게 넣는지가 거의 다 달랐다. 이 글에는 앞의 구조에서 무엇이 불편했고 뒤의 구조가 그걸 어떻게 풀었는지 적었다. Helm 과 Kustomize 를 겹쳐 쓰면서 새로 밟은 함정도 같이 적었다.IntroHelm 자체는 바뀌지 않았다. 바뀐 건 Helm 이 맡는 범위다. 예전에는 렌더, 환경 구분, 이미지 태그, 시크릿을 다 Helm values 가 .. 2026. 9. 27.

티스토리툴바