최근 업무나 공부를 하면서 CSV 타입의 파일을 사용하는 경우가 종종있다.

 

단순한 텍스트 형식의 파일이므로 메모장 같은 Viewer를 이용하거나

CLI 환경에서는 `cat` 명령어만으로도 내용을 확인할 수 있기에 편리하긴 하지만...

 

그냥 일반적은 텍스트 파일 처럼 보게 되면

데이터를 살펴보기에 불편하긴 하다.

 

 

1. Download CSV

  - 테스트 해보기 위해 CSV 파일 하나를 다운로드 받아놓자

$ wget https://web.stanford.edu/class/archive/cs/cs109/cs109.1166/stuff/titanic.csv

 

 

2. Basic

  - 보통 `cat` 형식으로 해당 파일을 보면 이렇다.

$ cat titanic.csv

 

3. Tidy Viewer (tv)

  - CSV 형식의 파일을 예쁘게 출력해주는 아이가 있다.

    - https://github.com/alexhallam/tv

 

  - Ubuntu 환경을 위해 deb 패키지를 제공해준다.

 

    ① Version Check

      - 현재 사용할 수 있는 버전을 확인해보자

        . https://github.com/alexhallam/tv/releases

 

    ② Download

$ wget https://github.com/alexhallam/tv/releases/download/0.0.21/tidy-viewer_0.0.21_amd64.deb

 

    ③ Install

$ sudo dpkg --install tidy-viewer_0.0.21_amd64.deb

 

    ★ 오류

      - Ubuntu 18.04 환경에서 아래와 같은 설치 오류가 발생했다.

      - 관련 이슈는 아래와 같이 reporting 되어 있다.

        . https://github.com/alexhallam/tv/issues/52

 

      - 일단 깨끗하게 오류난 패키지 설치 과정을 청소하자.

$ sudo dpkg --purge tidy-viewer

 

      - 위 이슈에서 제안한 해결 방법으로 설치를 해보자

$ sudo snap install --edge tidy-viewer

 

    ④ alias

      - 편한 사용을 위해 alias 설정까지 해보자

        . bashrc

$ echo "alias tv='tidy-viewer'" >> ~/.bashrc
$ source ~/.bashrc

        . zshrc

$ echo "alias tv='tidy-viewer'" >> ~/.zshrc
$ source ~/.zshrc

 

4. tv

  - 이제 예쁘게 잘 보이는지 확인해보자

$ tv titanic.csv

 

  - 에휴... 오류다.

 

  - 다음 처럼 하면 잘 된다

$ cat titanic.csv | tv

 

 

어?! 이쁘고 깔끔하다!

 

 

설치할 때 문제가 좀 있었고, 사용할 때에도 좀 불편한 점이 있긴한데... 이쁘다!

 

Ubuntu 20.04에서 해보면 문제 없이 사용할 수도 있을 것 같은데...

20.04 환경까지 켜서 확인해보긴 지금 귀찮아서 ^^

 

 

조금 더 지켜보고 내 기본 사용환경에 포함시키는 방향으로 해봐야겠다 !

 

 

반응형

 

정말 간만에 해보는 git 설치.

거기에다가 windows 10 환경은 정말 정말 오랜만이다.

 

 

1. Homepage

   - 모든 시작은 홈페이지

   - https://git-scm.com/

 

2. Download & Install

   - 홈페이지에서 친절하게 알맞은 아이를 추천해준다.

   - 오른쪽 모니터 화면에 있는 `Download for Windows`를 클릭해서 다운로드 후 설치 진행하자.

   - 잘 모르겠으면 추천하는대로 `Next`를 선택하면 된다 ^^

   - 개인적인 취향으로 기본 에디터를 선택하면 되는데, 저는 `nano`를 좋아하므로... ^^

 

3. Test

   - 잘 설치되었는지 확인해보자.

   - 윈도우즈의 `cmd`를 이용해서 해도 되지만, 이왕이면 `Git Bash`로 한 번 해보자.

   - 시작 메뉴에서 `Git Bash`를 클릭하자.

   - 그리고 실행

$ git --version

 

끝~

반응형

'SCM > Git-GitHub' 카테고리의 다른 글

github.dev (Web-IDE)  (1) 2021.11.03
git switch/restore (git 새로운 명령어)  (1) 2021.10.17
GitHub Copilot 처음 써보기  (0) 2021.07.26
GitHub CLI (GitHub Command line)  (0) 2020.09.20
git clone [bare/mirror] 에 대해서 알아보기  (0) 2020.01.01

 

개인적인 취향으로 Windows 환경에서

개발 비스무리한 것을 하는걸 별로 좋아하지 않지만

이번에 뭔가 해볼 일이 있어서... ^^

 

일단 Python 3.6 이상의 버전 설치가 필요하니 Go! Go! (여기에선 최신 버전은 3.9.7을 설치할 예정임!)

 

 

1. Download and Install

   - 아래 경로에 접속하면 알아서 현재 운영체제에 맞는 버전을 링크해준다.

   - https://www.python.org/downloads/

   - 다운로드 받은 후, 그냥 추천해주는대로 클릭 클릭 하면 설치 완료

 

 

2. PATH 설정

  - 설치가 완료되었지만, 제대로 사용하려면 PATH 설정을 해줘야 한다.

 

  ① 제어판

      - 시작 메뉴의 기어 모양 버튼을 통해 "제어판" 실행

 

   ② 고급 시스템 설정

      - 검색창에서 `고급 시스템 설정`을 타이핑 해서 나오는 결과를 클릭

 

   ③ 환경 변수

      - 속성창에서 `환경 변수` 선택

 

   ④ 시스템 변수 - PATH

      - 하단에 있는 `시스템 변수`에서 `PATH` 항목 찾으면 된다.

 

   ⑤ PATH - 새로만들기

      - `새로만들기`로 추가하면 된다.

      - 21-10-02 기준 Python 3.9.7 에서는 아래 경로였다. (2개 추가해야 한다)

      - 물론 사용자 명칭은 각자 환경에 따라서...

C:\Users\<사용자>\AppData\Local\Programs\Python\Python39\
C:\Users\<사용자>\AppData\Local\Programs\Python\Python39\Scripts

 

3. 동작 테스트

   - 잘 되었는지 테스트 해보자 ~

 

   - 시작 메뉴에서 `cmd`라고 타이핑을 한 뒤, `명령 프롬프트` 클릭

 

   - 명령어를 넣어보고 그림과 같은 결과가 나오면 성공이다.

> python --version

> pip --version

   - 위 2개 명령어만 잘되면 된다 ^^

 

반응형

 

 

이런 이미지들을 볼 때마다

"우와~!! 멋지다~!!"

감탄만 했었는데...

 

위성 사진은 물론이고

해류의 흐름

바람의 방향

PM2.5 현황 등

별의 별 정보들을 눈으로 볼 수 있게 해주는

정말 훌륭한 사이트를 찾았다.

 

https://www.windy.com/

 

웹사이트도 정말 훌륭하지만,

스마트폰 앱으로도 있다.

windy.com 으로 검색하면 된다.

 

앱도 정말 훌륭하다.

 

캡쳐한 이미지를 보면 알겠지만

한글 지원도 잘 해주고 있다.

 

무조건 강추!!!

 

반응형

 

파이썬 라이브러리를 활용한 데이터 분석 2판

 

표지

 

이번에 보게된 책은

"데이터 분석을 위해 파이썬 라이브러리를 사용하는 방법"을

알려주는 교과서와 같은 유명한 책이다.

 

 

교과서와 같은 책이라고 해서

오래된 책이라고 생각할 수도 있는데

오래된 책 맞다.

 

그렇다고 해서 'out of date' 된 책은 아니다.

 

제목에도 써있는 것처럼

"2판"으로 나왔기 때문이다.

 

2판 5쇄

 

거기에다가 5쇄까지 찍었다.

유명한 책인 것은 분명하다.

 

2판

 

결론적으로 2019년에 2판으로 업데이트 했고

내용은 지금도 유효하다!!!

 

 

 

"학습 환경"

이 책에서 제안하는 학습 환경은

Anaconda 설치해서

IPython 또는 Jupyter Notebook

사용하는 것이다.

 

IPython & Jupyter

 

Jupyter Notebook의 근간이 IPython 이라는 것을

처음 알았다 @.@

 

 

추가적으로 IDE(통합 개발 환경)를 소개해주기는 하는데,

결국은 IPython 또는 Jupyter Notebook을

사용하는 것을 권장하고 있다.

IDE

VSCode(Visual Studio Code) 언급이 없는 것으로 보아

2019년 이전에 작성한 책이 맞는 것 같다 ^^

하지만, 공부에는 지장이 없다 !!!

 

 

 

책 내용은

기본 자료형부터 설명을 시작하면서

Numpy와 Pandas를 중심으로

너무나 잘 설명해주고 있다.

 

책 내용도 훌륭하지만,

코드 예제 데이터는 꼭 찾아보길 바란다.

https://github.com/wesm/pydata-book

 

단순히 샘플 코드만 있는 것이 아니라

Jupyter Notebook 파일로 제공해주면서

설명하는 내용까지 담겨있다.

 

예제 코드

 

최근 많은 분들이 계속 관심을 많이 갖고 있는

Machine Learning, Deep Learning, Big Data 등의

공부를 하게 되면

반드시 거쳐가는 것이 바로

Python 특히, Numpy & Pandas 라이브러리에 대해서

공부를 하게 된다.

 

이 때, 정말 많은 도움이 될 책으로 추천할 수 있을 것 같다!!!

 

 

 

이 책을 보면서 특히 호감이 들었던 부분이

바로 "Chapter 11. 시계열" 이다.

 

시계열 데이터

 

개인적으로 Python으로 작업하면서

많은 고생을 했던 (즉, 시간을 엄청 많이 빼았겼던)

부분이 바로 "날짜" & "시간" 이었다.

 

즉, "시계열" 데이터 인데,

이것을 하나의 챕터로 깊게 다뤄주고 있어서

정말 감동했다.

 

 

 

이 책에 대해서 짧게 서평하자면

Python으로 데이터를 다루고 싶은 모든 분들에게 추천하는 책이다.

 

Numpy, Pandas는 물론이고

기본 내장 데이터형부터 시작해서

고급 데이터 분석까지 차분히 설명해주고 있다.

 

 

 "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

 

반응형

 

예전에도 NFS Server 설치를 알아봤었다.

  - https://www.whatwant.com/entry/NFSNetwork-File-System-기본-설정하기-Ubuntu-1404-1204

 

하지만 시간도 꽤 흘렀고,

Ubuntu 버전도 예전과 달라졌으니 새로 진행해보려 한다.

 

 

0. 설치 환경

  - VirtualBox 버전 6.1.26 r145957 (Qt5.6.2)

  - Ubuntu 18.04.6 LTS

  - Ubuntu 20.04.3 LTS

 

 

1. NFS Package 설치

  - 가능한 Ubuntu에서 배포하는 기본 패키지를 사용하겠다

master$ sudo apt install nfs-common nfs-kernel-server portmap

 

 

2. 디렉토리 생성

  - NFS 용도의 디렉토리를 만들고 권한을 설정하자

master$ sudo mkdir /srv/nfs

master$ sudo chmod 777 /srv/nfs

 

 

3. 접근 가능 호스트 목록 등록

  - 어디에서 접근할지 정의하자

master$ sudo nano /etc/exports
...
/srv/nfs 192.168.100.*(rw,sync,no_root_squash,no_subtree_check)

 

 

4. 서비스 리스타트

  - 설정 적용을 위해 서비스 재시작!

master$ sudo service nfs-kernel-server restart

 

 

5. 확인 (Server)

  - 지금 서비스 되고 있는 NFS 확인

master$ showmount -e 127.0.0.1

Export list for 127.0.0.1:
/srv/nfs 192.168.100.*

 

 

6. 확인 (Client)

  - 정말 연결이 잘되는지 확인

  - 이하 과정은 NFS 설치한 Server 말고 다른 Server에서 (/etc/exports 설정한 IP 대역에 있는) 수행

worker1$ sudo apt install nfs-common

worker1$ sudo mkdir /srv/nfs-client

worker1$ sudo mount -t nfs 192.168.100.200:/srv/nfs /srv/nfs-client
mount.nfs: access denied by server while mounting 192.168.100.200:/srv/nfs

 

  - 어?! access deny ?!

  - `/etc/hosts` 파일에 별도로 등록이 된 IP인 경우에 정책 적용이 제대로 안될 수 있다.

master$ sudo nano /etc/exports
...
/srv/nfs 192.168.100.*(rw,sync,no_root_squash,no_subtree_check) worker1(rw,sync,no_root_squash,no_subtree_check) 

 

  - 이제 다시 mount를 해보면, 된다.

worker1$ sudo mount -t nfs 192.168.100.200:/srv/nfs /srv/nfs-client

 

  - 아무런 메시지가 없으면 된 것이다.

worker1$ cd /srv/nfs-client

worker1$ touch temp.txt

 

  - NFS Server 측에서 확인해보면 보인다.

master$ cd /srv/nfs

master$ ls -al

 

  - 확인 다 했으면, umount 하면 된다.

worker1$ cd /srv

worker1$ sudo umount -t nfs 192.168.100.200:/srv/nfs /srv/nfs-client

 

 

자세한 옵션 등의 정보는 기존 포스팅을 참고해주세요~

  - https://www.whatwant.com/entry/NFSNetwork-File-System-기본-설정하기-Ubuntu-1404-1204

 

반응형

'잘난놈되기' 카테고리의 다른 글

kubectl 설치 (in Ubuntu)  (0) 2021.08.30
한글 지원되는 Ubuntu Docker Image 만들기  (0) 2021.07.27
bpytop 설치 (Ubuntu 18.04)  (2) 2020.12.31
하드디스크 용량 분석 (SpaceSniffer)  (0) 2020.12.28
Docker Hub 활용  (0) 2020.11.14

 

GCP, AWS와 같은 Cloud 업체에서 제공해주는 Managed K8s 환경을 사용하는 것이 아니라,

Local 환경에서 직접 K8s를 설치하는 경우

Ingress를 이용하기 위해서는 추가적인 설치를 해야 한다.

 

다른 네트워크 관련된 것들과 마찬가지로

Ingress도 여러가지 중에 선택적으로 설치해서 사용해야 한다.

 

직접 설치해서 사용하는 경우 일반적으로 Nginx 기반의 Ingress를 선택한다.

그런데, 이 부분에서 고생을 했던 이유가 Nginx 기반 Ingress 자체도 종류가 여러가지라는 것이다.

 

그 중에서 대표적인 Nginx Ingress Controller는 다음의 2가지 이다.

  - kubernetes/ingress-nginx

  - nginxinc/kubernetes-ingress

 

첫번째 것은 Kubernetes 진영에서 배포하고 있는 ingress-nginx 이고,

두번째 것은 Nginx 진영에서 배포하고 있는 nginx-ingress 이다.

 

두 배포판의 차이점을 정리한 내용은 다음 링크에서 확인해보면 된다.

  - https://docs.nginx.com/nginx-ingress-controller/intro/nginx-ingress-controllers

 

 

 

 

기능적으로 Nginx에서 배포하는 것이 좀 더 다양한 것 같기는 한데,

아무래도 Kubernetes 문서에서 보이는 Ingress 내용들의 기준이 되는 것은

`kubernetes/ingress-nginx`일 것이다.

 

 

 

그런데, 문제는 Kubespray로 Kubernetes를 설치할 때

addon으로 ingress를 선택하게 되면

이 때 설치되는 것이 'kubernetes/ingress-nginx'가 아니다.

(잘못알고 있을 수도 있으니, 정확히 알고 계신 분들 계시면 제보 바랍니다)

 

 

 

그래서,

Kubespray를 이용해서 Kubernetes를 설치할 때

addon 설정할 때 ingress를 선택하지 말고

나중에 직접 Ingress를 설치하는 방법으로 하고자 한다.

 

 

Kubernetes는 설치를 마친 상태에서

Ingress 설치를 하는 과정으로 진행해보자.

 

Reference

  - https://github.com/kubernetes/ingress-nginx/

  - https://kubernetes.github.io/ingress-nginx/deploy/

 

 

다양한 환경에서의 설치 방법이 각각 있지만,

우리가 여기에서 살펴볼 것은 Bare-Metal 환경을 기준으로 하겠다.

  - https://kubernetes.github.io/ingress-nginx/deploy/#bare-metal

 

그리고, 이 방법은 `Nodeport` 방식으로 설정된다.

(LoadBalancer가 있으면 그것을 이용하겠지만, 개인적으로 구축한 K8s 환경에서는...)

 

 

 

사실, 설치 방법은 너무나 쉽다.

단 1줄 !!!

 

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.0.0/deploy/static/provider/baremetal/deploy.yaml

 

정말 중요한 것은

잘 동작하는지 검증을 해보는 것일 것이다.

 

Namespace로 작업 공간 확보한 다음

Deployment 만들고 Service 만들어서

Ingress로 접근하도록 해보자.

 

 

① 따로 방을 잡아놓기 위해 Namespace 만들고,

$ nano 01.Namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: test-ingress

 

② Deployment를 이용해 Pod를 만들어 놓자

$ nano 02.Deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deploy

spec:
  replicas: 3

  selector:
    matchLabels:
      app: web

  template:
    metadata:
      name: web-pod
      labels:
        app: web

    spec:
      containers:
      - image: whatwant/node-web:1.0
        name: web
        ports:
        - containerPort: 8080
          protocol: TCP

 

③ Pod들을 연결할 Service를 만들자

$ nano 03.Service.yaml
apiVersion: v1
kind: Service
metadata:
  name: web-svc

spec:
  ports:
  - port: 80
    targetPort: 8080

  selector:
    app: web

 

지금까지 만들어 놓은 YAML을 실행하자

$ kubectl create -f ./01.Namespace.yaml

$ kubectl create --namespace=test-ingress -f ./02.Deployment.yaml

$ kubectl create --namespace=test-ingress -f ./03.Service.yaml

 

 

이제, 본론이다!

Ingress를 만들어서 Service를 외부로 오픈해보자.

$ nano ./04.Ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /

spec:
  rules:
  - http:
      paths:
      - path: /test
        pathType: Prefix
        backend:
          service:
            name: web-svc
            port:
              number: 80

 

만들어 놓은 YAML을 실행하자

$ kubectl create --namespace=test-ingress -f ./04.Ingress.yaml

 

 

이제 Web-Browser로 확인을 하면 되는데,

ingress-nginx가 지금 어떤 IP의 어떤 Port로 서비스 되고 있는 것일까?

$ kubectl get services --namespace=ingress-nginx

NAME                                       TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                               AGE
ingress-nginx-controller                 NodePort    10.233.29.64    <none>          80:32035/TCP,443:32407/TCP   11h
ingress-nginx-controller-admission   ClusterIP     10.233.38.85    <none>          443/TCP                              11h

 

`ingress-nginx`는 지금 `NodePort` 방식으로 서비스 되고 있으므로 IP는 node들의 IP 아무것이나 ...

Port는 http는 32035, https는 32407을 사용하고 있음을 확인할 수 있다.

(당연히 각자의 환경에서 Port는 다를 수 있다)

 

 

그러면, 이제 웹브라우저로 확인해보자.

 

 

어?! 왜 안되지 ?!

멍청하면 손발이 고생한다고... 이 문제를 해결하려고 3일 넘게 잠도 잘 못자고 정말 고생했다 ㅠㅠ

 

엄청난 구글링 시도를 했지만 속시원한 해결책을 찾지 못하다가... 결국은 방법을 찾았다.

 

 

일단, ingress-nginx의 로그를 확인해야 했었다.

$ kubectl logs --namespace=ingress-nginx ingress-nginx-controller-57ffff5864-p52bb -f
-------------------------------------------------------------------------------
NGINX Ingress controller
  Release:       v1.0.0
  Build:         041eb167c7bfccb1d1653f194924b0c5fd885e10
  Repository:    https://github.com/kubernetes/ingress-nginx
  nginx version: nginx/1.20.1

-------------------------------------------------------------------------------

W0918 04:05:51.466315       6 client_config.go:615] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
I0918 04:05:51.466488       6 main.go:221] "Creating API client" host="https://10.233.0.1:443"
I0918 04:05:51.476011       6 main.go:265] "Running in Kubernetes cluster" major="1" minor="20" git="v1.20.7" state="clean" commit="132a687512d7fb058d0f5890f07d4121b3f0a2e2" platform="linux/amd64"
I0918 04:05:51.723687       6 main.go:104] "SSL fake certificate created" file="/etc/ingress-controller/ssl/default-fake-certificate.pem"
I0918 04:05:51.740515       6 ssl.go:531] "loading tls certificate" path="/usr/local/certificates/cert" key="/usr/local/certificates/key"
I0918 04:05:51.769911       6 nginx.go:253] "Starting NGINX Ingress controller"
I0918 04:05:51.783535       6 event.go:282] Event(v1.ObjectReference{Kind:"ConfigMap", Namespace:"ingress-nginx", Name:"ingress-nginx-controller", UID:"9e277dae-b490-471f-806f-c88f9554da0f", APIVersion:"v1", ResourceVersion:"32531", FieldPath:""}): type: 'Normal' reason: 'CREATE' ConfigMap ingress-nginx/ingress-nginx-controller
I0918 04:05:52.972526       6 nginx.go:295] "Starting NGINX process"
I0918 04:05:52.972784       6 nginx.go:315] "Starting validation webhook" address=":8443" certPath="/usr/local/certificates/cert" keyPath="/usr/local/certificates/key"
I0918 04:05:52.972852       6 leaderelection.go:243] attempting to acquire leader lease ingress-nginx/ingress-controller-leader...
I0918 04:05:52.973417       6 controller.go:150] "Configuration changes detected, backend reload required"
I0918 04:05:52.985822       6 leaderelection.go:253] successfully acquired lease ingress-nginx/ingress-controller-leader
I0918 04:05:52.992811       6 status.go:84] "New leader elected" identity="ingress-nginx-controller-57ffff5864-p52bb"
I0918 04:05:53.007665       6 status.go:204] "POD is not ready" pod="ingress-nginx/ingress-nginx-controller-57ffff5864-p52bb" node="worker2"
I0918 04:05:53.043798       6 controller.go:167] "Backend successfully reloaded"
I0918 04:05:53.043952       6 controller.go:178] "Initial sync, sleeping for 1 second"
I0918 04:05:53.044349       6 event.go:282] Event(v1.ObjectReference{Kind:"Pod", Namespace:"ingress-nginx", Name:"ingress-nginx-controller-57ffff5864-p52bb", UID:"6b9e8d63-801f-4ac2-8533-8a0164e792bf", APIVersion:"v1", ResourceVersion:"32685", FieldPath:""}): type: 'Normal' reason: 'RELOAD' NGINX reload triggered due to a change in configuration
I0918 05:25:59.272392       6 main.go:101] "successfully validated configuration, accepting" ingress="web-ingress/test-ingress"
I0918 05:25:59.278726       6 store.go:361] "Ignoring ingress because of error while validating ingress class" ingress="test-ingress/web-ingress" error="ingress does not contain a valid IngressClass"
I0918 05:38:54.461751       6 store.go:336] "Ignoring ingress because of error while validating ingress class" ingress="test-ingress/web-ingress" error="ingress does not contain a valid IngressClass"
I0918 05:39:44.049518       6 main.go:101] "successfully validated configuration, accepting" ingress="web-ingress/test-ingress"
I0918 05:39:44.053660       6 store.go:361] "Ignoring ingress because of error while validating ingress class" ingress="test-ingress/web-ingress" error="ingress does not contain a valid IngressClass"

 

그렇다. 원인은 로그에 다 있었다 ㅠㅠ

 

`IngressClass`가 문제란다.

이걸 해결하면 되는데...

$ nano ./04.Ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    ingressclass.kubernetes.io/is-default-class: true

spec:
  rules:
  - http:
      paths:
      - path: /test
        pathType: Prefix
        backend:
          service:
            name: web-svc
            port:
              number: 80

 

annotation 한 줄 추가해주면 된다.

 

 

모든 Ingress에 저렇게 입력하기 싫다면,

기본 IngressClass nginx를 수정하면 된다.

 

`ingress-nginx` namespace에 있는 ingressclass를 살펴보면 `nginx` 이름으로 존재하고 있다.

$ kubectl get ingressclasses --namespace=ingress-nginx 

NAME    CONTROLLER             PARAMETERS   AGE
nginx     k8s.io/ingress-nginx     <none>          12h

 

edit 하면 되는데,

막간을 이용해서 tip 하나 추가하자면,

기본적으로 `kubectl edit`를 하게되면 기본 에디터로 `vi`가 실행된다.

 

vi를 싫어하는 나같은 사람들을 위해 에디터 변경을 하는 방법이 있다.

$ export KUBE_EDITOR=nano

 

그리고, 이제 edit를 해보자.

$ kubectl edit ingressclasses nginx --namespace=ingress-nginx
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"networking.k8s.io/v1","kind":"IngressClass","metadata":{"annotations":{},"labels":{"app.kubernetes.io/component":"controller","app.kubernetes.io/instance":"ingress-nginx","app.kubernetes.io/managed-by":"Helm","app.kubernetes.io/name":"ingress-nginx","app.kubernetes.io/version":"1.0.0","helm.sh/chart":"ingress-nginx-4.0.1"},"name":"nginx"},"spec":{"controller":"k8s.io/ingress-nginx"}}
  creationTimestamp: "2021-09-18T04:05:10Z"
  generation: 1
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/version: 1.0.0
    helm.sh/chart: ingress-nginx-4.0.1
  name: nginx
  resourceVersion: "102271"
  uid: 13fa4354-bb3d-4dee-ae56-5d14600354cb
spec:
  controller: k8s.io/ingress-nginx

 

나머지는 모르겠고 ... 위에 색으로 칠한 부분만 추가되어 있으면 된다.

 

 

문제 해결을 위해 열심히 구글링 하면서 알게된 지식 추가 공유 !

 

- Ingress 생성할 때, 연결하고자 하는 Service가 있는 namespace에 같이 존재해야 한다

  . Ingress Controller는 전체 namespace를 바라보고 있기에 가능하다.

 

- Ingress와 연결되는 Service는 Cluster IP와 매핑이 된다.

  . 그래서 Service는 Nodeport 타입이어도 되고, 아니어도 된다.

 

 

이번에는 여기까지~

반응형

최근 software version을 살펴보면 1.x 버전을 넘어서는 것들을 보기 힘들다.

 

꼰대 아재가 알고 있는 기존 상식으로

외부에 출시하려면 1.0 version을 찍어야 하는데 말이다.

 

v0.1 이면 `이제 막 만들기 시작했군~`

v0.9 이면 `오~! 이제 곧 출시를 앞두고 있군~`

v1.0 이면 `축하! 축하! 이제 출시했네~`

v1.1 이면 `출시하자마자 발견한 버그들 fix 했구만~`

 

뭐 이런 식이었다.

 

 

하지만, 최근 트렌드는 `zero based versioning scheme` 이다!

 

 

https://0ver.org

 

 

software version에 대해서 최근 별 생각이 없었는데,

위 사이트를 발견하고는 `아~!! 그렇군~!!` 하면서 무릎을 탁! 치게 되었다. (너무 아재스러운 표현인가?!)

 

 

가장 대표적인 software versioning scheme은 다음의 3가지 방식이다.

 

① Semantic Versioning (https://semver.org/)

  - 전통적인 방식의 versioning scheme 이다.

    . 호환되지 않는 API 변경이 있으면 major version 올리고

    . 호환되는 기능 추가이면 minor version 올리고

    . 버그 수정했으면 patch version 올리는 방식

 

② Calendar Versioning (https://calver.org/)

  - Ubuntu, Unity 등에서 채택한 날짜를 기본으로하는 versioning scheme

    . Ubuntu : YY.0M.MICRO (20.04 - 2020년 04월)

    . Unity : YYYY.MINOR.MICRO (2020.1.0 - 2020년)

 

③ Zero(0) based Versioning (https://0ver.org)

  - 규칙은 간단하다. 1 버전이 넘어가지 않으면 된다.

    . React Native : 0.65.0-rc.4 (6.4년째)

    . scikit-learn : 0.24.2 (11.6년째)

 

 

 

최근 유행이 ③번이라는 것은 대부분의 개발자들이 동의할 것이다.

 

 

 

그러면, 대체 왜 0ver(ZeroVer) 방식이 유행을할까?

 

안타깝게도 위 사이트(https://0ver.org)에서 그 이유를 명시적으로 설명해주지 않는다.

 

그러면 개인적으로 그 이유를 상상해볼 수 밖에 없는데...

 

 

1. 예전에는 완성된 제품을 출시하는 방식으로 software를 생각했지만,

   인터넷의 발달로 connected world가 되었기에 언제든 업데이트할 수 있는 환경을 갖췄고

   그래서 이제는 software를 완성된 제품으로 바라보기 보다는

   버그가 좀 있더라도 일단 출시하고, 문제점을 발견하면

   빨리 고쳐서 업데이트 하면 된다고 생각하기 시작했고

   그래서 부담스러운 major version 체계보다는 0-based version 체계를 택한 것이 아닐까?!

 

2. 앞의 맥락과 같은 내용일 수도 있는데,

   기존에는 major version 출시를 하나의 큰 마케팅 포인트로 보았고, 하나의 완제품으로 보았기에

   자동차 모델 하나를 출시하는 것과 유사하게 여겼고 그렇기에 지속적인 지원을 해줘야 했다.

   그렇기에 다음 major version을 출시하게 되었더라도 (새로운 모델 출시)

   기존 major version에 대한 지원을 계속 해줘야 하는 어려움이 있었다.

   하지만, 0-based version 체계에서는?! 안해줘도 될 것만 같은...

 

3. version up을 한다는 것의 의미를 생각해봐야 한다.

   새로운 기능을 추가하거나, 버그를 고치거나, 보안상 이슈가 있는 것을 해결해 나가는 과정이다.

   그렇다면 과거 버전을 유지하는 것이 의미가 있을까?

   물론 여러가지 이유로 기존 버전의 필요성이 있을 수는 있겠지만

   중요한 것은 latest version 이다.

   그렇다면, 기존 version scheme 보다는 0-based version이 오히려 적합하지 않을까?!

 

 

재미있는 사이트를 찾게 되어

그냥 이런 저런 생각을 해봤다.

 

 

PS. 아! 노파심에서 말하지만 위 홈페이지의 about을 꼭 확인해보기 바란다!!! (0ver 추천 홈페이지가 아니다!!!)

반응형

'소프트웨어' 카테고리의 다른 글

Adobe Photoshop Lightroom v1.3  (0) 2007.11.20
freemind v0.8.0  (0) 2006.08.31

+ Recent posts