Cloud Computing On Demand

.env 파일을 이용해 환경 변수를 설정하는 방식이 널리 사용되고 있습니다.
개인적으로는 dotenv 패키지를 이용해서 .env 파일을 사용중인데요
오랜만에 프로젝트 환경을 구성 하다보니 dotenv 패키지가 없더군요.

그런데!

pip install dotenv를 아무리 해도 설치되지 않는 당혹스러움을 마딱드렸습니다. 
패키지가 없어진건가? 사내 네트워크에서 막힌건가? 온갖 생각을 하다 찾아보니...
dotenv의 패키지 이름은 python-dotenv 였습니다 ㅠㅠ 
오랜만에 만난 그 이름... 어쩐지 익숙합니다.

pip install python-dotenv

당황하지 말고, python-dotenv를 설치하십시오, 닝겐!

CentOS를 비롯한 Redhat 계열에서는 Yum을 이용해 패키지를 관리합니다.
간혹 yum 으로 패키지를 설치하다 패키지 데이터베이스를 열 수 없다는 에러를 만날 수 있습니다.
영문 기준으로 rpmdb open failed 라는 메세지가 바로 그것이죠.

이런 상황을 해결하는 가장 쉬운 방법은 RPM DB 삭제입니다.
DB를 삭제한다고 뭔가 큰 일이 일어나는 것은 아닙니다. 
DB 자체에 뭔가 이슈가 생긴 경우이기 때문에 
DB 파일 삭제후 다시 생성하면 됩니다. 

rm -f /var/lib/rpm/_db*
rpm -vv --rebuilddb

리모트에 새로 생성된 브랜치가 있다면 가져오도록 하기 위해 다음의 명령을 사용합니다.
이 명령을 이용해 새로 생성된 브랜치의 정보를 로컬에 기록해 둘 수 있습니다.
네, 기록만 하는 것이고 소스코드를 실제로 가져오는 것은 아닙니다.

git remote update

그런데 이렇게 기록해둔 브랜치 정보는
특정 브랜치의 폐기와 같이 변화된 내용을 자동으로 반영하지는 못합니다. 
물론, `git branch -D` 옵션으로 로컬에서 정보를 지울 수 있지만
브랜치가 많은 경우에는 좋은 선택지가 아닙니다.

이럴 때는 다음의 명령을 이용해 특정 원격지의 브랜치를 확인하고
삭제된 브랜치는 로컬 브랜치 기록에서도 삭제하도록 할 수 있습니다.

git fetch {리모트명} --prune

혹은

git remote prune {리모트명}

참 쉽죠?

매일 매일 하지 않으면 다 까먹는게 k8s인 것 같습니다. 
여느 오픈소스들과 마찬가지로 마이너버전 업데이트가 이루어지더라도
여러가지 변경되는 점들이 워낙 많기 때문일 것 같습니다.

그 중에서도! 
ServiceAccount를 생성했을 때 같이 생성되던 Token이 만들어지지 않는 것은
분명 꼼꼼히 이것저것 살피지 않았다면 빠지기 쉬운 함정인 것 같습니다 ㅠㅠ

네, 1.24 버전 이후의 k8s를 사용한 클러스터로 작업중이라면 
ServiceAccount와 함께 수동으로 Token을 위한 Secret을 생성해야 합니다. 
예를 들어 보겠습니다. 

apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: default
  name: drone-bot

1.24 버전까지는 위와 같이 ServiceAccount를 생성하면 
`drone-bot-token-j13b7`와 같은 스타일의 토큰이 자동으로 생성되었습니다. 

1.24 이후 버전부터는 보안 강화를 위해 토큰을 자동으로 생성하지 않습니다. 
따라서 아래와 같이 별도로 Secret 오브젝트를 생성해 줘야 합니다. 

apiVersion: v1
kind: Secret
metadata:
  name: drone-bot-secret
  namespace: default
  annotations:
    kubernetes.io/service-account.name: drone-bot
type: kubernetes.io/service-account-token

이렇게 하고나면 ServiceAccount에 대한 Token을 획득할 수 있습니다. 

% k get secret drone-bot-secret -n default
NAME               TYPE                                  DATA   AGE
drone-bot-secret   kubernetes.io/service-account-token   3      15s

% k get secret drone-bot-secret -n default -o yaml
apiVersion: v1
data:
  ca.crt: LS0tLS1CRUdJTi...
  namespace: ...
  token: ZX...
...

왜 자동으로 Token이 생성되지 않는지 한참 헤메였는데...
알게 모르게 k8s 버전이 1.25로 바뀌었는데 그걸 모르고 클러스터 만들고 삽질을 했었네요...
여러분은 삽질하지 마시라고 공유해 드립니다!

드문드문 k8s를 사용하다보니 매번 반복적으로 쉬운 것들을 잊곤 합니다.
오랜만에 또 새로운 클러스터를 새로운 환경에 만드느라 삽질하는 요즈음,
잊었던 것들을 또 하나씩 적어 볼까 합니다.

ServiceAccount 생성

이번에는 CI/CD 연동 등을 통해 k8s 클러스터에 대한 작업을 같이 수행하고 있습니다. 
빌드 배포시마다 k8s 환경이 잘 구축되어 있는지를 점검하려는 욕심에 그만...
그래서 ServiceAccount 의 생성이 필요해졌습니다.

요약하면... 걍 만들면 됩니다.
그래도 우리는 선언적으로 만드는게 좋겠죠.
네, drone을 쓰려는 중입니다 ㅎㅎ

apiVersion: v1
kind: ServiceAccount
metadata:
  name: drone-bot

Role 선언

이번엔 ServiceAccount에 연결할 Role을 정의해 봅시다.
Role을 정의하려다 보니 apiGroups와 해당되는 resources
그리고 사용 가능한 verbs가 뭐가 있는지 또 헤메기 시작합니다. 

% kubectl api-resources -o wide

kubectl로 위 명령을 입력하면 필요한 모든 것들이 쫘아악~
필요한 권한과 대상 리소스에 대한 내용을 확인하면 됩니다. 
늘 느끼는 거지만 APIVERSION은 왜 이리 아스트랄한지...

몇 가지 골라서 일단 때려 넣습니다.
보안 헛점은 일단 고려치 않습니다 ㅎㅎ
필요한 동사들은 조금 더 발라내 봐야겠네요. 

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: drone-bot
rules:
  - apiGroups: [""]
    resources: ["configmaps", "secrets", "services", "namespaces"]
    verbs: ["get", "list", "create", "update", "patch", "delete"]
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "create", "update", "patch", "delete"]
  - apiGroups: ["networking.k8s.io"]
    resources: ["ingresses"]
    verbs: ["get", "list","watch", "create", "update", "patch", "delete"]

복수형에 주의하시고, 
엉뚱한 apiGroups에 넣지 않도록 주의합시다!

ServiceAccount와 Role을 연결하는 RoleBinding

이렇게 두개의 k8s 객체를 만들었으니 이제 연결해야겠죠?
RBAC으로 권한 부여를 할 것이기 때문에 RoleBinding을 하면 됩니다. 
이름이 다 drone-bot이라 헷갈릴 수 있지만...

metadata.name 은 RoleBinding의 이름이고
subjects.kind[].name은 생성한 ServieAccount의 이름이며
roleRef.name은 생성한 Role의 이름입니다. 

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: drone-bot
subjects:
  - kind: ServiceAccount
    name: drone-bot
roleRef:
  kind: Role
  name: drone-bot
  apiGroup: rbac.authorization.k8s.io

그럼... 이제 생성해보러...

얼마전 회사 공식 유튜브 채널에서 개발자 밋업 영상을 찍었습니다.
근래에 회사 공식 유튜브나 블로그에 뭔가 기여한 기억도 없고 하여
겸사겸사 "NGINX 쿡북" 2판 번역서 출간 홍보도 할겸 전격 촬영에 임했습니다.

유튜브 라이브로 진행되는 회사 관련 액티비티는
신년대응 관련해서 진행했던 세션 이후로 간만이라.. 감회가 새로웠습니다.
재미있는 것은 이 영상을 찍은 이후에도 회사내에서 NGINX 관련한 이슈들에 난입할 계기가 있었고
세션에서 했던 이야기들이 헛되지 않았구나 하는 생각을 했었습니다 ^^;

아무쪼록 재미있게 봐주시면 좋겠습니다.
이것도 벌써 찍은지 2주가 넘어가는..ㅎㅎ

https://developer.zendesk.com/documentation/integration-services/developer-guide/jq-cheat-sheet/#creating-an-array

jq 는 한번 대대적으로 정리하자고 생각만 하면서 못하고 있는 중입니다.
매번 안쓰던 방식으로 구현해야 할 시점이 되면 검색하느라 시간을 낭비하고...
전자책 출판이라도 목표로 좀 대대적인 정리를 해보고 싶은 느낌입니다!

여튼, 꽤 쏠쏠한, 특히 배열 관련한 많은 내용이 있어서 퍼와봅니다.

제작년에 출간했던 <NGINX 쿡북>의 개정판 번역서 작업을 완료했습니다!
지난주부터 여러 서점에 배포되기 시작했고
온라인 서점에서도 쉽게 구입하실 수 있습니다. 

초판 번역은 참 버거웠는데, 개정판 작업은 의외로 빠르게 끝낼 수 있었습니다.
리버스 프록시의 대표주자이자 k8s ingress controller의 대표주자인 NGINX!
아직 익숙하지 않다면 <NGINX 쿡북> 개정판으로 NGINX를 정복해 보는건 어떨까요!?

본 포스팅은 본인 책에 대한 판매 링크를 포함하고 있습니다. 
판매를 통해 소소한 수수료를 지급받을 수 있습니다!