728x90

기초적인 것들이 늘 가장 어려운 법입니다. 여러 환경에 구축된 쿠버네티스 클러스터를 다루는 상황이 되니 이게 뭥미~ 하는 생각이 들면서 머릿속이 하얗게 변했습니다. 가령 로컬 환경에 시험용 클러스터가 구축되어 있고 (이하 docker-desktop) 구글 클라우드 플랫폼에 클러스터를 하나 구성한 상황에서 (이하 k8snopd) kubectl 로 양쪽 클러스터를 제어하는 방법의 정리입니다. 


kubectl 설정 파일 확인하기 

kubectl 을 사용하고 있다면 .kube/config 파일에 (맥 기준) 액세스 할 수 있는 클러스터 정보가 기록되어 있습니다. 언급 드린 것처럼 로컬 환경과 GCP 환경에 클러스터가 구성되어 있습니다. 로컬 환경은 맥 용 Docker Desktop 에서 클러스터를 만들었고, GCP 는 gcloud CLI 를 이용해서 원격지 환경에 클러스터를 만들고 접근할 수 있게 가이드를 따랐습니다.

이 상태라면 .kube/config 에는 두 클러스터 접근을 위한 설정이 들어가 있게 됩니다. 설정된 내용은 cat 등으로 조회할 수도 있지만 kubectl 을 이용해서 조회하는 것이 더 깔끔합니다. 

% kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://kubernetes.docker.internal:6443
  name: docker-desktop
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://xx.xxx.xxx.xx
  name: gke_k8s-practice-310514_asia-northeast1-a_k8snopd
contexts:
- context:
    cluster: docker-desktop
    user: docker-desktop
  name: docker-desktop
- context:
    cluster: gke_k8s-practice-310514_asia-northeast1-a_k8snopd
    user: gke_k8s-practice-310514_asia-northeast1-a_k8snopd
  name: gke_k8s-practice-310514_asia-northeast1-a_k8snopd
current-context: gke_k8s-practice-310514_asia-northeast1-a_k8snopd
kind: Config
preferences: {}
users:
- name: docker-desktop
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
- name: gke_k8s-practice-310514_asia-northeast1-a_k8snopd
  user:
    auth-provider:
      config:
        access-token: ya29.a0AfH6SM...........................
        cmd-args: config config-helper --format=json
        cmd-path: /Downloads/google-cloud-sdk/bin/gcloud
        expiry: "2021-04-15T09:00:09Z"
        expiry-key: '{.credential.token_expiry}'
        token-key: '{.credential.access_token}'
      name: gcp

먼저 clusters 노드로 두개의 cluster 가 지정돤 것이 보입니다. name 키에 지정된 이름이 각각 다른게 보이시죠? GCP 에 만든 클러스터 이름은 다소 복잡합니다. GCP 의 리전명 등이 포함되어 있네요. 이어서 각 클러스터에 접근할 때 사용되는 사용자 토큰 등의 정보가 이어집니다. 

 

kubectl 에서 클러스터 바꾸는 방법

위의 설정에서 주목할 값 중 하나는 current-context 입니다. 제 경우는 GCP 를 나중에 설정해서 그런지 GCP 가 현재 컨텍스트라고 지정되어 있습니다. 즉, kubectl 명령을 사용하면 특별히 컨텍스트를 지정하지 않으면 GCP 의 클러스터로 명령을 날리게 됩니다. 한번 해볼까요?

% kubectl get nodes
NAME                                     STATUS   ROLES    AGE   VERSION
gke-k8snopd-default-pool-8130c84d-371t   Ready    <none>   63m   v1.18.16-gke.502
gke-k8snopd-default-pool-8130c84d-l26t   Ready    <none>   63m   v1.18.16-gke.502
gke-k8snopd-default-pool-8130c84d-xrkt   Ready    <none>   63m   v1.18.16-gke.502

 

그렇다면 로컬 클러스터 (docker-desktop) 로 컨텍스트를 바꾸어 노드 목록을 받아오고 싶다면 어떻게 해야 할까요? kubectl 이 제공하는 --context 매개변수를 이용해서 클러스터의 컨텍스트명을 입력해 주면 쉽게 대상 클러스터를 바꿀 수 있습니다. 함 해보죠!

% kubectl get nodes --context docker-desktop
NAME             STATUS   ROLES    AGE     VERSION
docker-desktop   Ready    master   5d23h   v1.19.3

 


 

 

728x90
728x90

거의 두, 세달정도 코드 작업을 못했던 것 같습니다. 아예 안한건 아니었지만 외부 소스코드에 대한 분석 이외에는 딱히 코드를 보지 않았더니 반대급부로 git에 대한 명령어들이 기억속에서 사라지기 시작했습니다 ;;;

그런데 오늘! 제가 작성했던 코드가 잘 동작하지 않는 예외 케이스가 발생되었다는 소식을 접수했습니다. 급한일을 부랴부랴 끝내고 비주얼 스튜디오 코드를 열고나니... 원격 브랜치의 저장소들이 그 사이 변경된 내용이 있을텐데 하는 불안감이 엄습했습니다. 

원래의 저장소, 포크한 내 저장소, 그리고 동료의 작업 저장소. git remote -v 명령으로 확인해보니 아직까지 원격 저장소 목록은 잘 저장이 되어 있었습니다. 이 저장소들에서 변경된 내용을 어떻게 가져오지... 하면서 좀 뒤져서 다시 기억을 살려보았습니다!


로컬 저장소에 지정된 원격 저장소 목록 확인

로컬 저장소에서 git 명령을 이용하여 추가 되어 있는 원격 저장소의 목록을 확인할 수 있습니다. 

% git remote -v
origin  git@git.nopd.company.com:nopd/client.git (fetch)
origin  git@git.nopd.company.com:nopd/client.git (push)
upstream        git@git.nopd.company.com:awesomeproject/client.git (fetch)
upstream        git@git.nopd.company.com:awesomeproject/client.git (push)
myfriend        git@git.nopd.company.com:myfriend/client.git (fetch)
myfriend        git@git.nopd.company.com:myfriend/client.git (push)

origin은 제 개인 저장소, upstream은 프로젝트의 원래 저장소, 그리고 myfriend는 동료의 저장소 입니다. 

 

각 저장소의 업데이트 사항 가져오기

이제 각 저장소의 업데이트 사항을 가져오는 명령을 입력해 보겠습니다. 

% git remote update
Fetching origin
Enter passphrase for key '/.ssh/id_rsa': 
Fetching upstream
Enter passphrase for key '/.ssh/id_rsa': 
Fetching myfriend
Enter passphrase for key '/.ssh/id_rsa': 
From git.nopd.company.com:myfriend/client
 * [new branch]      ISSUE_1 -> myfriend/ISSUE_1
 * [new branch]      ISSUE_2 -> myfriend/ISSUE_2
 * [new branch]      ISSUE_3 -> myfriend/ISSUE_3
   50c7deb..ff405ce  master -> myfriend/master

동료가 이렇게 열심히 일하는 동안 저는 놀았구나 하는 자괴감과 함께... 각 저장소의 변경 사항 확인시마다 SSH 키 값을 입력해서 동기화를 마쳤습니다. 

 

모든 브랜치 확인해보기

이제 로컬 저장소에 있는 브랜치와 원격의 브랜치를 확인해 보도록 하겠습니다. 명령은 git branch -a 입니다. 

% git branch -a 
  branch1
* branch2
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin...
  ...
  remotes/upstream/master
  remotes/upstream...
  ...
  remotes/myfriend/master
  ...

 

원격 브랜치 가져오기

마지막으로 작업하고 싶은 브랜치를 현재 로컬 브랜치로 가져오도로 하겠습니다. 특별히 upstream 에 변경된게 없어서 로컬 (origin/master) 브랜치에 업스트림 브랜치 (upstream/master) 의 변경사항을 땡겨오기로 했습니다. 로컬 브랜치를 하나 더 따려다... 일단 마스터에 합치고 브랜치를 나누는게 편해서... ㅎㅎ

% git pull upstream master
Enter passphrase for key '/.ssh/id_rsa': 
From git.nopd.company.com:awesomeproject/client
 * branch            master     -> FETCH_HEAD
Updating 48bc962..ff405ce
Fast-forward
 .....													  |  15 +++++++-
 .....													  | 220 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------------------
 .....													  |   8 ++--
 package-lock.json                                        |  29 ++++++++------
 package.json                                             |   2 +-
 5 files changed, ...

 


매일매일 쓰지 않으면 잊어버리는 것들. 시간을 꼭 내서 하루 한줄의 코딩, 하루 한 번의 명령어 입력도 잊지 말고 해야겠습니다 ㅎㅎㅎ 그리고 미래의 나를 위해 블로그에 살짝~ 남겨두는 활동을 꼭 꼭! 해야겠습니다!

728x90
728x90

인증서를 다루다보면 가장 많이 사용하는 것이 OpenSSL 입니다. OpenSSL 의 명령들중 자주 사용하는 것들을 기억해두면 생활이 편리해지고 퇴근시간이 빨라지는 장점이 있습니다. 서버나 로컬 터미널 환경에 미리 alias 로 몇 가지 등록해 두면 두고두고 편리하게 사용할 수 있는 명령들을 몇 가지 정리해 보았습니다. 


로컬 환경의 RSA 인증서의 Private Key 확인하기

$ openssl rsa -in private_key_file.key -check
RSA key ok
writing RSA key
-----BEGIN RSA PRIVATE KEY-----
...

 

로컬 환경의 X509 인증서 (보통 SSL 인증서라 부르죠) 내용 확인하기

$ openssl x509 -in certificate_file.crt -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            11:22:33:aa:44:bb:55:66:77:88:99:cc
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign RSA OV SSL CA 2018
        Validity
            Not Before: Apr 22 03:16:05 2021 GMT
            Not After : May 23 03:16:05 2022 GMT
        Subject: C=KR, ST=Seoul-si, L=Kangseo-gu, O=NoPD Corp, CN=*.nopd.me
        ...

 

원격지 환경의 인증서 Trust Chain 확인하기

$ openssl s_client -showcerts -connect www.naver.com:443
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA
verify return:1
depth=0 C = KR, ST = Gyeonggi-do, L = Seongnam-si, O = NAVER Corp., CN = *.www.naver.com
verify return:1
---
Certificate chain
 0 s:/C=KR/ST=Gyeonggi-do/L=Seongnam-si/O=NAVER Corp./CN=*.www.naver.com
   i:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
-----BEGIN CERTIFICATE-----
...

 

 

원격지 환경의 X509 인증서 상세 내용 확인하기

$ openssl s_client -connect www.naver.com:443 | openssl x509 -noout -text
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA
verify return:1
depth=0 C = KR, ST = Gyeonggi-do, L = Seongnam-si, O = NAVER Corp., CN = *.www.naver.com
verify return:1
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            05:75:b5:1c:cb:25:fc:9c:ef:cb:6e:63:fe:1a:45:29
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA
        Validity
            Not Before: May 30 00:00:00 2020 GMT
            Not After : Jun  8 12:00:00 2022 GMT
        Subject: C=KR, ST=Gyeonggi-do, L=Seongnam-si, O=NAVER Corp., CN=*.www.naver.com
        ...
        

 

 

 

728x90
728x90

새로운 개발환경은 늘 어색합니다. 플러터(Flutter)를 안드로이드 스튜디오 환경에서 다시 공부하기 시작하면서 매일매일 새로운 느낌으로 시행착오를 겪고 있습니다. Mac 운영체제의 Big Sir의 업데이트 때문에 설치후 재기동을 하고 난 뒤 안드로이드 스튜디오에서 겪은 문제에 대한 이야기입니다.

운영체제 업데이트전까지 아무런 문제 없이 안드로이드 스튜디오에서 플러터로 코드를 만들고 안드로이드 시뮬레이터를 이용해 디버깅을 하고 있었습니다. 그런데 업데이트 설치후에 갑자기 안드로이드 스튜디오가 시뮬레이터에서 앱을 실행하지 못하고 에러를 토하는 현상을 맞딱들였습니다. 

집나간 시뮬레이터들... 아빠가 잘못했다, 어서 돌라오렴!

안드로이드 스튜디오를 여러번 재기동해도 시뮬레이터의 목록이 보이지 않았습니다. 안드로이드 스튜디오에서 코드를 실행하면 시뮬레이터가 기동은 되었지만 (왜지...) 디버거가 연결이 안되고 앱이 배포되지 않았습니다. 안드로이드 시뮬레이터를 관리하는 AVD Manager 를 이용해 만들어 둔 이미지를 개별적으로 실행하면 <Unable to locate adb>라는 에러 메세지가 출력되었습니다. 

 

AVD Manager 의 에러 : Unable to locate adb

 

구글에서 검색을 해보니 이 현상이 일어나는 원인중 대표적인 것이 안드로이드 디버거인 adb 의 경로가 제대로 설정되지 않아 실행되지 않는 경우라는 이야기가 많았습니다. 안타깝게도 제 경우에는 터미널에서 adb 가 아주아주 원활히 잘 실행되고 있었기 때문에 환경변수에서 path 설정이 잘못된 것으로는 생각되지 않았습니다. 

SDK 설정을 보려면 File > Project Structure 메뉴를 사용합니다.

 

그러던 중 <Project Structure> 에서 SDK 설정이 제대로 되지 않았거나 삭제된 경우 (아마도 업데이트의 여파?) 비슷한 문제를 겪었다는 글을 발견할 수 있었습니다. 밑져야 본전, 정말로 SDK 설정이 <갑자기> 사라진 것인지 확인해 보기로 했습니다. 설마 안드로이스 스튜디오가 그런 일을 저질렀겠냐는 생각을 하던 바로 그 순간...

헐... No SDK 라니...

 

저는 제 눈을 의심해야 했습니다. Project 의 SDK가 <No SDK>를 가리키고 있었습니다. 누가 이런 짓을 한 걸까요? 그건 아무도 모릅니다. 며느리도 모릅니다. 다만, SDK 설정이 사라졌다는 사실이 중요한 것이고 이것을 바로 잡아 문제가 해소되는지 확인해야 했습니다. 

 

드롭다운 리스트를 열고 로컬 환경에 설치된 안드로이드 SDK중 28버전의 API 를 다시 선택했습니다. 그리고 창을 닫고 기도를 했습니다. 집나간 시뮬레이터가 어서 돌아오게 해주세요. 모든걸 용서하겠다고...

집에 돌아온 시뮬레이터

 

오오오오.. 아무 것도 없던 디바이스 선택 드롭다운 리스트에 만들어둔 시뮬레이터가 똬악하고 보였습니다. 프로젝트를 실행해보니 디버거 연결도 잘 되고 앱도 정상적으로 배포되는 것을 확인할 수 있었습니다. 왜 이런일이 일어난 것인지는 알아낼 수 없었지만 유사한 현상이 발생헀을 때, 이제 당황하지 않고 문제를 처리할 수 있을 것 같은 자신감이 샘솟았습니다. :-)

728x90

+ Recent posts