본문 바로가기
반응형

DevOps128

[Git] : issues와 milestones으로 프로젝트 관리하기 msa 토이 프로젝트를 간단히 만들면서 git flow 또한 적용해 보고 싶었다. 그 전에 간단하게 먼저 이슈와 마일스톤을 사용하는 방법에 대해 알아보고 적용해 보았다. 어느 정도 혼자 테스트 해 보고 진행했다. FirstService와 SecondService는 사전에 테스트 해 본 마일스톤이다. 이번에는 FrontService를 만들어 본다. New milestone을 눌러 새로운 마일스톤을 생성해 준다. 마일스톤 이름과 만료일자, 설명을 적어준다. 혼자 해 보는 것이라 따로 만료일을 적어주진 않았다. 이렇게 생성하고 나면 FrontService가 마일스톤 탭에 잘 나타난다. 아까 설명도 간단하게 적어주어서 같이 표시된다. 빨간 박스에 밑 줄을 보면 complete는 0%, open과 closed도 .. 2022. 6. 1.
[Git] : git pull request 활용하기 (프로젝트 관리) 협업이나 혼자 프로젝트를 진행하면서 오늘 작업한 내용을 기능 단위로 관리하고 체크하기 위해 git pull request를 사용하기로 했다. 오픈 소스 프로젝트에 기여할 때는 fork를 하고 아래를 따라하면 된다. 테스트로 build.gradle에 메일 관련 라이브러리 의존성을 추가해주었는데 이것을 pull request로 올려보겠다. git checkout -b mail **git checkout -b 브랜치명** 명령어를 통해 기능 혹은 사용자 단위로 브랜치명을 생성해 준다. 보통은 기능 단위로 브랜치명을 생성해 주는 것 같다. -b 가 브랜치 생성을 말한다. git branch -a 명령어로 브랜치를 확인할 수 있다. git branch -d 브랜치명 로컬 브랜치 삭제도 가능하다. git push .. 2022. 4. 27.
[Kubernetes] : Configmap과 Secret 쿠버네티스 YAML 파일과 설정값을 분리할 수 있는 Configmap과 secret이라는 오브젝트가 있다. Configmap에서는 설정 값을 저장하고, Secret에서는 노출되면 안 되는 값을 저장한다. 이 두 개를 사용하면 애플리케이션과 설정값을 별도로 분리해 관리할 수 있는 장점이 생기게 된다. 📖 ← [ 시작하세요! 도커/쿠버네티스 ] 책을 참고하여 공부하였습니다. 2022. 3. 24.
[Kubernetes] : 네임스페이스에 종속되는 쿠버네티스 오브젝트와 독립적인 오브젝트 네임스페이스를 사용하면 쿠버네티스 리소스 사용 목적에 따라 논리적 격리가 가능하지만 모든 리소스가 네임스페이스에 의해 구분되진 않는다. A 네임스페이스에서 포드를 만들면 A 네임스페이스에만 보인다. 이것을 오브젝트가 네임스페이스에 속한다고 하는데 이 반대로 속하지 않는 오브젝트도 있다. Nodes가 그 중 하나이다. Nodes는 쿠버네티스 클러스터에서 사용되는 저수준의 오브젝트이며, 네임스페이스에 의해 구분되지 않는다. kubectl api-resoucres --namespaced=false 네임스페이스에 속하지 않는 오브젝트의 종류는 위 명령어로 확인이 가능하다. 확인해 보면 Nodes는 물론이고 네임스페이스 자체도 네임스페이스에 종속되지 않는다는 것을 확인할 수 있다. 📖 ← [ 시작하세요! 도커/쿠.. 2022. 3. 24.
[Kubernetes] : 네임스페이스의 서비스에 접근하기 쿠버네티스 클러스터 내부에서는 같은 네임스페이스 내의 서비스에 접근할 때에는 서비스 이름으로만으로 접근할 수 있다. 다른 네임스페이스에 존재하는 서비스에는 서비스 이름만으로는 접근이 불가능하다. 다른 네임스페이스에 존재하는 서비스에 접근하는 방법은 다음과 같다. ..svc처럼 서비스 이름 뒤에 네임스페이스 이름을 붙이면 다른 네임스페이스의 서비스에도 접근이 가능하다. kubetcl delete namespace 이름 kubectl delete -f YAML파일명 두 명령어로 네임스페이스를 삭제할 수 있다. 네임스페이스를 삭제하면 모든 리소스도 같이 삭제된다. 📖 ← [ 시작하세요! 도커/쿠버네티스 ] 책을 참고하여 공부하였습니다. 2022. 3. 24.
[Kubernetes] : 네임스페이스 사용하기 네임스페이스는 YAML 파일에 정의해 사용이 가능하다. apiCersion: v1 kind: Namespace metadata: name: production YAML 파일을 적어준다. kubectl apply -f production-namespace.yaml kubectl create namespace production 둘 중 하나의 명령어로 생성이 가능하다. kubectl get ns | grep production production이라는 네임스페이스가 정상 생성이 되었는지 체크한다. kubectl get pods --all-namespaces 모든 네임스페이스의 리소스를 확인할 수 있다. 📖 ← [ 시작하세요! 도커/쿠버네티스 ] 책을 참고하여 공부하였습니다. 2022. 3. 24.
[Kubernetes] : 네임스페이스 기본 이해 네임스페이스를 간단하게 사용해 본다. 네임스페이스는 쿠버네티스에서 namespace 또는 ns라는 이름으로 사용할 수 있고 kubectl get namespaces 명령어로 확인이 가능하다. kubectl get namespaces kubectl get ns 둘 중 아무거나 사용해도 상관없다. 기본적으로 네임스페이스는 생성하지 않아도 3개가 존재한다. 각 논리적인 리소스 공간이라서 각 네임스페이스에는 포드, 레플리카셋, 서비스 같은 리소스가 따로 존재한다. kubectl get pods --namespace default default라는 이름의 네임스페이스에 생성된 포드를 확인해 본다. 이 default 네임스페이스는 쿠버네티스를 설치하면 자동으로 사용되도록 설정되어 있는 네임스페이스이다. —names.. 2022. 3. 23.
[Kubernetes] : 네임스페이스(Namespace) 언급. 도커, 도커 스웜 모드는 컨테이너를 논리적으로 구분하는 방법이 없었다. 용도에 따라 컨테이너와 그에 관련된 리소스를 구분해 관리할 수 있는 논리적 그룹이 있으면 좀 더 편할 것이다. 쿠버네티스에서 이런 일을 네임스페이스(Namespace)가 해준다. 네임스페이스는 포드, 레플리카셋, 디플로이먼트, 서비스와 같은 쿠버네티스 리소스들이 묶여 있는 하나의 가상 공간이나 그룹으로 이해하면 된다. 여러 개의 네임스페이스를 사용하면 마치 하나의 클러스터에서 여러 개의 가상 클러스터들을 동시에 사용하는 것 처럼 느낄 수 있다. 📖 ← [ 시작하세요! 도커/쿠버네티스 ] 책을 참고하여 공부하였습니다. 2022. 3. 23.
[Kubernetes] : 온프레미스 환경에서 LoadBalancer 타입의 서비스 사용 LoadBalancer 타입의 서비스는 클라우드 플랫폼에서 사용되지만 필요에 따라 직접 보유하고 있는 온프레미스 서버에서도 LoadBalancer 타입을 사용할 수 있다. 쿠버네티스가 직접 제공하는 기능은 아니고 MetaILB라는 오픈소스 프로젝트를 사용하면 된다. 단, 유지보수가 지속적이지 않을 수 있으므로 유의해야 하고 공식 문서를 참고하면 된다. 📖 ← [ 시작하세요! 도커/쿠버네티스 ] 책을 참고하여 공부하였습니다. 2022. 3. 22.
[Kubernetes] : Service 종류 포드에 접근할 수 있는 규칙을 정의하는 서비스 리소스를 생성해야 하는데 어떻게 접근할 것인지에 따라 종류가 여러 개로 세분화 된다. 자주 사용되는 서비스 타입은 아래와 같다. ClusterIP 타입 쿠버네티스 내부에서만 포드에 접근할 때 사용한다. 외부에 노출하지 않아 클러스터 내부에서 사용되는 포드에 적합하다. NodePort 타입 포드에 접근할 수 있는 포트를 클러스터의 모든 노드에 동일하게 개방해 외부에서 포드에 접근할 수 있다. 접근 가능한 포트는 랜덤이고 특정 포트로 접근하게 설정도 할 수 있다. LoadBalancer 타입 클라우드 플랫폼에서 제공하는 로드 밸런서를 동적으로 프로비저닝해 포드에 연결한다. 외부에서 포드에 접근할 수 있지만 AWS, GCP 등 클라우드 플랫폼에서만 사용이 가능하다.. 2022. 3. 21.
[Kubernetes] : Service : 포드를 연결하고 외부에 노출하기 디플로이먼트를 통해 생성된 포드에 접근하기 위해 kubectl describe 명령어로 포드의 내부 IP를 직접 확인해 포드로 직접 접근을 할 수 있었지만 문제가 있다. 먼저, 로컬 개발 환경이나 쿠버네티스 클러스터 내부에서만 사용할 수 있다는 점하고 영속적이지 않아 항상 변할 수 있따는 점이다. 때문에 여러 개의 디플로이먼트를 하나의 애플리케이션으로 연동하기 위해 서로를 발견(Discovery)할 수 있는 방법이 필요하다. YAML 팡리 중 containerPort 항목이 포드 애플리케이션이 사용할 내부 포트를 정의하는데 이 항목을 정의했다고 해서 포드가 외부로 노출되는 것은 아니다. 노출되기 위해서는 Service 오브젝트를 생성해야 한다. 이 Service 오브젝트는 여러 기능이 있지만 핵심 기능은.. 2022. 3. 21.
[Kubernetes] : 디플로이먼트를 사용하는 간단한 이유 디플로이먼트를 사용하는 이유는 애플리케이션의 업데이트와 배포를 편리하게 하기 위함이다. 디플로이먼트는 컨테이너 애플리케이션을 배포하고 관리하는 역할을 담당한다. 쿠버네티스에서도 공식적으로 디플로이먼트를 사용할 것을 권장하고 있다. 📖 ← [ 시작하세요! 도커/쿠버네티스 ] 책을 참고하여 공부하였습니다. 2022. 3. 21.
[Kubernetes] : 디플로이먼트 사용하기 레플리카셋으로 마이크로서비스 구조의 컨테이너를 구성할 수 있을 것 같지만 실제 쿠버네티스 운영 환경에서 레플리카셋을 YAML 파일에서 사용하는 경우는 거의 없다. Deployment라는 오브젝트를 YAML 파일에 정의해서 사용한다. 이 디플로이먼트 오브젝트는 레플리카셋의 상위 오브젝트여서 생성 시 이에 대응하는 레플리카셋도 생성된다. kubectl get deploy 생성된 디플로이먼트의 목록을 확인한다. kubectl get replicasets kubectl get pods 포드 개수를 유지시켜주는 것은 레플리카셋이다. 디플로이먼트와 같이 레플리카셋이 생성된 것임을 알 수 있다. kubectl delete deploy my-nginx-deployment 디플로이먼트를 삭제하면 레플리카셋과 포드도 삭제.. 2022. 3. 21.
[Kubernetes] : 레플리케이션 컨트롤러 vs 레플리카셋 이전 쿠버네티스에서는 레플리카셋이 아니라 레플리케이션 컨트롤러(Replication Controller)라는 오브젝트를 통해 포드의 개수를 유지했다. 하지만 지금은 레플리카셋을 사용한다. 이 두 오브젝트의 차이는 표현식 기반의 라벨 셀럭터를 사용할 수 있다는 것이다. 예를 들면 아래와 같다. selector: matchExpressions: - key: app values: - my-nginx-pods-label - your-nginx-pods-label operator: In template: ... key가 app인 라벨을 가지고 있는 포드들 중 values 항목에 정의돈 값들이 존재(In)하는 포드들을 대상으로 한다는 의미이다. app: my-nginx-pods-label 라벨을 가지는 포드뿐만 아.. 2022. 3. 19.
[Kubernetes] : 레플리카셋의 동작 원리 레플리카셋의 동작 원리 레플리카셋을 생성,삭제하면 포드도 생성,삭제가 되니 연결된 것 처럼 보이지만 실제로는 연결되어 있지 않고 느슨한 연결을 유지하고 있다. 이런 느슨한 연결은 Label Selector를 통해 이루어진다. 라벨은 포드 등 쿠버네티스 리소스를 분류할 때 유용하게 사용할 수 있는 메타데이터이다. 라벨은 쿠버네티스 리소스의 부가적인 정보를 현할 수 있고 서로 다른 오브젝트가 서로를 찾아야 할 때 사용되기도 한다. 레플리카셋은 정의된 라벨을 통해 생성해야 하는 포드를 찾는다. 예를 들어 A라벨을 가지는 포드의 개수가 replicas항목에 3개로 정의되어 있는데 개수가 일치하지 않다면 포드를 정의하는 포드 템플릿 항목의 내용으로 포드를 생성한다. kubectl apply -f nginx-pod.. 2022. 3. 19.
[Kubernetes] : 레플리카셋 사용 Nginx 포드를 생성하는 레플리카셋을 만들어본다. apiVersion: apps/v1 kind: ReplicaSet metadata: name: replicaset-nginx spec: replicas: 3 selector: matchLabels: app: my-nginx-pods-label template: metadata: name: my-nginx-pod labels: app: my-nginx-pods-label spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 replicaset-nginx.yaml 파일을 작성한다. 리소스의 고유한 이름은 쿠버네티스 오브젝트에서도 설정이 가능하다. kubectl apply.. 2022. 3. 18.
[Kubernetes] : Replica Set, 레플리카 셋을 사용하는 이유 포드는 여러 컨테이너를 추상화해 하나의 애플리케이션으로 동작하게 하는 컨테이너 묶음이다. YAML에 포드만 정의해 생성하면 이 포드의 Lifecycle은 어떻게 될까? kubectl delete -f nginx-pod-ubuntu.yaml kubectl get pods kubectl delete pods my-nginx-pod 포드를 삭제하면 그 포드의 컨테이너도 삭제되어 쿠버네티스에서 영원히 사라지게 된다. 이렇게 YAML에 정의해 생성하면 오직 쿠버네티스 사용자에 의해 관리된다. 하지만 외부 사용자의 요청을 처리해야 하는 마이크로 서비스 구조의 포드면 이런 방식을 사용하기 어렵다. 이렇게 YAML 파일에 정의해 사용하는 것은 여러 문제와 한계가 있고 이런 점을 해결해 사용하기 위해 replica se.. 2022. 3. 17.
[Kubernetes] : 완전한 애플리케이션으로서의 pod 완전한 애플리케이션으로서의 포드 K8s는 1개의 컨테이너로 구성된 포드를 사용하는 경우가 많다. 그렇다면 왜 하나의 포드에 여러 개의 컨테이너가 포함되어야 하는지 의문점이 생기게 된다. 여기서 유의점은 하나의 포드는 하나의 완전한 애플리케이션이라는 점이다. Nginx 컨테이너는 그 자체로 완전한 애플리케이션이다. 떄문에 하나의 포드에 2개의 Nginx 컨테이너가 정의되는 것은 옳지 못 하다. 하지만 Nginx 컨테이너가 실행되기 위해 부가적인 기능이 필요하다면 추가 컨테이너를 포드에 포함시킬 수 있다. 이렇게 포드에 정의된 부가적인 컨테이너를 Sidecar(사이드카) 컨테이너라고 한다. 사이드카 컨테이너는 포드 내 다른 컨테이너와 네트워크 환경을 공유한다. 포드에 포함된 컨테이너들은 모두 같은 워커 노드.. 2022. 3. 17.
[CentOS] : MongoDB 간단 정의 및 yum을 통한 설치와 설정 셋팅 MongoDB 간단 정의 및 yum을 통한 설치와 설정 ( CentOS) MongoDB란? NoSQL에서 가장 많이 사용되는 데이터베이스이다. 높은 수준의 Java 기반 API를 제공하고 Spring Framework와 연동이 가능하다. MongoDB 버전은 Community 와 Enterprise Server로 구분된다. Enterprise Server의 추가 기능은 In-Memory Storage Engine(데이터 저장소를 메모리로 사용 가능)를 지원한다. 추가로 저장된 데이터를 암호화 하거나 LDAP, Kerveros를 통한 접근 제어가 가능하다. MongoDB 4.xx 변화도 있다. ACID(원자성,일관성,고립성,지속성)을 제공하고 트랜젝션을 제공한다. 특히 4.2 버전부터 (샤딩을 통한)분산된.. 2022. 3. 17.
[Kubernetes] : 포드 vs 도커 컨테이너 단일 컨테이너와 크게 다르지 않은 것 같지만 왜 포드를 사용할까? 쿠버네티스가 포드를 사용하는 이유는 여러 리눅스 네임스페이스를 공유하는 여러 컨테이너들을 추상화된 집합으로 사용하기 위해서이다. kubectl get pods 명령어를 출력했을 때 READY 항목에 1/1이 출력되었을텐데 Nginx 포드에 1개의 컨테이너가 정의되어 있고 준비되었다. 라는 뜻이다. 이처럼 보통 1개의 컨테이너로 포드를 구성해 사용하지만 꼭 1개로 구성해야 하는 것은 아니다. 네트워크 네임스페이스는 컨테이너의 고유한 네트워크 환경을 제공해 주는 역할을 담당한다. 다른 컨테이너를 추가해 2/2로 만든 뒤 하나의 컨테이너의 접속해서 HTTP 요청을 전송하면 다른 서버에서 응답이 도착하는 것을 확인할 수 있다. 📖 ← [ 시작하세.. 2022. 3. 16.
[Kubernetes] : 포드, Pod 사용하기 포드, Pod 사용하기 애플리케이션을 구동하기 위해 필수적으로 알아야 하는 몇 가지 오브젝트가 있는데 그것이 바로 포드, 레플리카셋, 서비스, 디플로이먼트이다. 쿠버네티스에서 컨테이너 애플리케이션의 기본 단위를 포드라고 한다. 포드는 1개 이상의 컨테이너로 구성된 컨테이너의 집합이다. 도커 엔진에서 기본 단위가 도커 컨테이너, 스웜 모드에서 기본 단위는 서비스인 것 처럼 쿠버네티스는 기본 단위로 포드를 사용한다. 1개의 포드엔 1개의 컨테이너가 존재 할 수도 있고 여러 개의 컨테이너가 존재 할 수도 있다. apiVersion: v1 kind: Pod metadata: name: my-nginx-pod spec: containers: - name: my-nginx:latest ports: - contain.. 2022. 3. 16.
반응형

티스토리툴바