티스토리

네른

검색하기

블로그 홈

네른

nairns.tistory.com/m

공부, 궁금했던 것, 프로젝트 등을 정리합니다

구독자: 0

방명록 방문하기

주요 글 목록

[분산처리] 서버 이중화(Duplication) 개요 고가용성을 보장하는 서버 환경이 필요해졌다. 그래서 가장 먼저 적용하기로 한게 서버 이중화. 그 중에서 앞쪽에서 유저의 요청이 들어왔을 때, 이를 분산하는 방법에 대해 조사했다. 서버 이중화란, 말 그대로 서버를 이중으로 구성하는 것. 보통 고가용성을 달성하기 위해 서버를 여러대 설치하는 경우가 많은데, 각 서버의 용도에 따라 이름이 나뉜다. 크게 Active-Standby(Passive) 와 Active-Active 형태로 나뉘게 된다! Active-Passive - 실제 요청을 받아 처리하는 Active 서버와, Active 서버에 장애가 발생할 때 대신 받아 요청을 처리하는 Passive 서버로 나뉨. - 즉, 평소에는 Passive 서버는 별다른 요청 처리를 수행하지 않음. 모든 요청은 Activ.. 공감수 0 댓글수 0 2022. 5. 23.
[Kubernetes] 쿠버네티스 환경 구성하기 - rook ceph, OCI registry, chartmuseum, ingress controller 앞선 글대로 Kubernetes를 설치하면, 말 그대로 kube cluster만 구성된 상태가 된다. 여기에 먼저 설정한 것들이 위에 적힌 것들이다. - rook ceph : kubernetes 환경 위에 가상 스토리지인 ceph를 배포하여 사용하게 해주는 도구. - chartmuseum : 프라이빗 차트 레포. helm chart를 사용할 때, 프라이빗 레포가 필요하다면 설치. - ingress controller : ingress rule을 적용하기 위해 필요한 controller - OCI registry : docker 환경을 이용한 프라이빗 레지스트리. 사용하는 환경이 프라이빗 레포에 레지스트리가 필요하고 helm chart로 관리를 하고자 하였기때문에 chartmuseum, OCI regist.. 공감수 0 댓글수 0 2022. 5. 23.
[Kubernetes] Kubernetes 기본 구성하기 앞에서 대시보드 구성을 먼저 쓰게된거같은데, 실제로는 클러스터 구성 후에 진행했던 내용이긴 하다. 어쩌다보니 베어메탈 위에 직접 kubernetes 클러스터를 구성하게 되었었다. 기존 클라우드를 이용해 구성했을때에 비해 그렇게 어려웠던 부분은 없었던거같지만 추억보정이 들어가있을 수 있으므로 한번 정리해보기로 했다. 쿠버네티스 클러스터를 구성하는 건 기본적으로 Installing kubeadm | Kubernetes Installing kubeadm This page shows how to install the kubeadm toolbox. For information on how to create a cluster with kubeadm once you have performed this installa.. 공감수 0 댓글수 0 2022. 5. 18.
[Kubernetes] Resource Request / Limit 쿠버네티스는 각 Pod별로 작동에 필요한 리소스를 지정하는 옵션이 있다. 지정하는 리소스는 대표적으로 CPU와 Memory가 있으며, 각각 request, limit 이라는 두 값을 입력해 주어야 한다. - 이 때 CPU의 리소스 단위는 상수(1.0) 혹은 m으로 표현되며 공식문서에 따르면, : 1.0 == 1개의 CPU 코어 : 100m == 0.1 == 100 밀리코어 라고 한다. - 메모리의 리소스 단위는 주로 M, G, T, P와 같은 단위를 쓰며 바이트 단위를 의미한다. : 128M == 128 메가바이트 : 혹은 2의 거듭제곱을 사용하는 방식인 128Mi 등이 있다. Request VS Limit Request와 Limit의 차이는 단순하다. Request는 컨테이너가 생성될 때 노드에 요청하.. 공감수 3 댓글수 0 2022. 5. 16.
[Kubernetes] Dashboard 설치 보통 yaml 파일을 새로 적용하려면 kubectl create -f 명령어를 사용하게 된다. 이와 별개로, 호스트나 파드의 상태를 한눈에 보고싶을 때 설치하게되는게 dashboard이다. dashboard에서 직접 yaml파일의 내용을 업로드해서 만들 수 도 있고, 파드나 노드의 상태를 보기에도 좋다. 로그를 볼 수도 있고, container shell에 접근할 수도 있다. kubectl이 익숙하지 않으면 잠시 써도 나쁘지 않을 것 같다. kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.4.0/aio/deploy/recommended.yaml 대시보드를 배포하는 명령어는 위와 같다. 공식적으로 제공되는 yaml과 이미.. 공감수 0 댓글수 0 2022. 5. 13.
[Kubernetes] Security Context 종종, Pod를 생성하고 나서 내부의 앱이 권한문제로 인해 정상적으로 동작하지 않을 때가 있다. 그럴 때 주로 사용한 방법이 Pod의 SecurityContext를 수정하는 것. SecurityContext란 Pod/Container의 권한을 수정하는 데 사용되는 기능으로, 프로세스의 사용자/그룹을 수정하거나 보안정책, 권한 등을 설정하게 된다. 대표적인 몇가지만 간단히 나열하자면, - hostPID/IPC : 해당 리소스가 node의 PID와 IPC를 사용할 수 있게되어 직접 통신이 가능해진다 - hostNetwork : 해당 리소스가 node의 network interface에 접근할 수 있게된다 - runAsUser: 해당 리소스의 사용자 ID(UID)를 지정한다. 디폴트 값이 0 이기에, 특정 U.. 공감수 0 댓글수 0 2022. 5. 13.
[Kubernetes] Service Account & Role 보편적으로 account라 하면, 해당 서비스에 접근하기 위한 유저의 계정을 생각한다. 그러나 kubernetes에서 account라 하면, 보편적으로는! service account를 의미한다고 보면 된다. 물론 일반적인 user account도 있지만, kubernetes는 그러한 유저 정보를 별도로 저장하지 않는다. - 단지 외부 서비스에 의한 인증(Oauth 등)을 제공만 할뿐, 별도로 저장해서 가지고있지 않다는 뜻. 그러면 service account란 뭘까. - 단순하게 말해서 kube에 접근하고자 하는 시스템의 계정이다. - 즉, kubernetes의 API를 이용해 kube를 수정하거나 조회하려면, 해당 시스템은 적절한 servica account를 가지고 있어야 한다는 것. - 생성은 복.. 공감수 0 댓글수 0 2022. 5. 13.
[logrotate] 로그 로테이션 로그 로테이션. 말 그대로 로그를 회전시키는 것. 로그 파일의 크기가 너무 커지는 것을 방지하기 위해, 로그 파일을 분산/갱신 하는 과정을 의미한다. Spring과같은 다양한 애플리케이션들은 기본적으로 로그 로테이션 방법을 내부적으로 지니고 있다. 그런데 만약 없다면?? 예를들어 database들 그런 것들을 위해 사용되는거이 리눅스의 기본 패키지 중 하나인 logrotate이다. logrotate는 cron을 기반으로 돌아간다고 생각하면 되는데, 당연하게도 주기적으로 로그를 갱신해야되므로 필요하다. 간단하게 구조를 보면 cron의 동작을 기술하는 부분 중, cron.daily 폴더 내부를 보면 logrotate파일이 있는 것을 볼 수 있다. 그리고, 해당 파일의 내부에는 /etc/logrotate.d .. 공감수 0 댓글수 0 2022. 5. 12.
[ElasticSearch] 번외 - ILM 적용 약간 번외 느낌인데, Elasticsearch를 사용하다가 쌓인 데이터를 어떻게 처리할까? 에 대해 고민하다가 찾아봤다. 디스크가 터질 것 같았기 때문. ILM(Index Lifecycle Management)인데, 말그대로 elasticsearch index들의 수명을 어떻게 처리할지이다. 주로 Hot, warm, cold, delete 페이즈를 지정해서 일정 기간이 지나도록 접근이 없거나 접근 횟수가 낮으면 중요도를 점점 낮추다가 삭제하는 방식. - 기본적으로 hot-warm-cold 방식을 기반으로 동작 - 자주 접근되는 인덱스는 hot, 일정 기간 이상 접근되지 않으면 warm -> cold 순으로 내려감 - cold 상태에서도 일정 기간 이상 접근되지 않으면(데이터 조회나 추가가 없으면) del.. 공감수 0 댓글수 0 2022. 5. 11.
[Kubernetes] EFK 적용 과정 (Elasticsearch, Fluentd, Kibana) - 2 지난번에 작성한 Fluentd 내용을 토대로, 실제 EFK 스택을 kube에 올릴 때 사용한 yaml을 정리하고자 한다. 해당 yaml들은 helm chart를 기반으로 작성되어있어 일부 변수가 포함되어있다. 실제로는 해당 부분을 직접 채워넣어 사용해도 되니까 우선은 helm chart 내용을 토대로 정리한다! 우선, 각 애플리케이션별 구성은 크게 다음과 같다. Fluentd - Deployment (HTTP 로그 수집용 / Side-car 형태의 로그 수집용) - ConfigMap - Service (HTTP 로그 수집용 Pod를 위한 서비스) - Ingress Elasticsearch - Deployment - Service - Ingress Kibana - Deployment - Service - .. 공감수 0 댓글수 0 2022. 5. 11.
[Kubernetes] EFK 적용 과정 (Elasticsearch, Fluentd, Kibana) - 1 보통 로깅을 위한 아키텍쳐라고 하면 ELK(Elasticsearch, Logstash, Kibana)의 구조를 생각하게 된다. 가장 유명한? 널리 알려진? 로깅/분석 스택이기 때문이다. Kubernetes 환경에서도, Kubernetes 자체의 로그 뿐 아니라 내부의 애플리케이션에 대한 로깅과 매니징이 필요하다. 그래서 사내에서 동작중인 앱에 대해 ELK 스택을 적용하고자 하였으나, CNCF stack을 찾아보니 Logstash보다는 Fluentd를 권장하고 있어 이를 사용하게 되었다. Fluentd에 대해 간단히 설명하자면 다음과 같다 - 오픈소스 기반의 로그 수집기 - HTTP, TCP, File 등 다양한 데이터 소스로부터 로그를 수집해 원하는 곳으로 전달(elasticseardch, s3)할 수 .. 공감수 0 댓글수 0 2022. 5. 10.
[Kubernetes] ConfigMap & Secret 본 글에서 알아볼 내용은, 쿠버네티스에서 환경변수, conf 파일 등을 어떻게하면 효율적으로, 편하게 사용하는지에 대한 내용. 실제 kubernetes를 이용하게 되면, 만약 conf 파일이 Pod 내에 있는 경우 이를 수정할 방법이 마땅치 않거나 매우 복잡. 그래서, 이를 조금 더 쉽게 하는 대표적인 두 리소스가 configMap과 secret. - 환경변수 혹은 설정파일을 일종의 변수로 두고 Pod가 생성될 때(배포될 때) 반영할 수 있도록! - 방법은 크게 두 가지로, 환경변수(env) 혹은 disk mount의 방법 ConfigMap - Key-Value 형태로 데이터를 저장할 수 있음 kind: ConfigMap apiVersion: v1 metadata: name: common-config n.. 공감수 0 댓글수 0 2022. 5. 2.
[Kubernetes] Deployment & Rolling Update 기존의 서비스들은 가용성을 유지하면서 애플리케이션을 업데이트하기 위해 블루-그린 업데이트 등의 방식을 사용해왔음. kubernetes에서는 이러한 업데이트를 '롤링 업데이트' 방식으로 처리함. - ReplicaSet 단위로 진행되며, 기존 ReplicaSet의 replica 수를 줄임과 동시에 새 ReplicaSet의 replica 수를 늘려서 유지되도록 이러한 과정을 추상화해두고, 이용하기 쉽게 해둔것이 바로 Deployment. 앞서 말했던것과 같이, deployment는 ReplicaSet의 추상화된 개념임을 유의 실제 deployment를 배포한 후, 다음과 같은 명령어로 기존 replicaset을 업데이트 할 수 있다. $ kubectl set image deployment DEPLOYMENT이.. 공감수 0 댓글수 0 2022. 5. 2.
[Kubernetes] Health Check Kube는 Pod의 health check를 이용해서 컨테이너를 자동으로 재시작할 수 있음 - 크게 Liveness / Readiness/ Startup Probe라는 세 방식이 있음 - 세 Probe 모두 다음과 같은 방법을 이용할 수 있음 1) Command Probe - 쉘 명령어를 수행하고, 결과값이 0이면 정상 livenessProbe: exec: command: ls -al 2) HTTP Probe - HTTP Get 메소드를 이용해 응답이 200대 혹은 300대인경우 정상 livenessProbe: httpGet: path: /test port: 8080 3) TCP Probe - 지정된 컨테이너에 TCP 연결을 수행해서 성공한경우 정상 livenessProbe: tcpSocket: port.. 공감수 0 댓글수 0 2022. 5. 1.
[Kubernetes] Kubernetes의 구조 - 컨트롤러 저번 포스트에서는 기본 오브젝트들에 대해 정리함. 이번에는 컨트롤러 - Replication Controller(ReplicaSet), Deployment, StatefulSet, DaemonSet, Job Controller 에 대해 정리하고자 함. Controller? - 쿠버네티스의 오브젝트를 관리해주는 것 Replication Controller (ReplicaSet) - 구 버전의 Replication Controller와 ReplicaSet은 동일. - Kube의 Pod 수를 일정하게 유지되도록 생성하고 관리하는 것이 주 역할. - Kube는 가용성 확보를 위해 동일한 Pod를 여러개 띄우게 되는데, 이를 replica로 묶어서 관리하게 됨 : 즉, 어떤 ReplicaSet의 replica 수.. 공감수 0 댓글수 0 2022. 4. 30.
[Kubernetes] Kubernetes의 구조 - Master/Worker, 기본 오브젝트 쿠버네티스는 매번 할때마다 새롭기때문에, 간단하게라도 정리해두고자 함. 매우 간단하게 정리할 예정임! Kubernetest의 구조 - 크게 Master node와 Worker node로 구성되어있음 Master - API 서버 : KUBE의 기능을 API 형태로 제공하는 서버 - etcd : Key-Value 구조의 DB로, 설정값, 클러스터의 정보 등을 저장하는 DB - Scheduler : Pod, 서비스 등을 워커노드에 적절하게 할당하는 역할을 담당 - Controller Manager : Replica, Service, Volume, Node Controller 등 다양한 컨트롤러를 생성하고 관리하는 역할 - DNS : KUBE는 리소스의 endpoint를 DNS로 관리함. 각 리소스의 IP는 동.. 공감수 0 댓글수 0 2022. 4. 30.
[CI/CD] Gitlab-ci.yml 작성 예제 - Docker Image Push 앞서 실행한 두 테스트 이후에, 우선적으로 이미지를 생성하는 작업을 진행하였다. 이유는 뒤이어 실행할 두 테스트 (SiteSpeed.io / JMeter)가 실제 동작중인 백엔드 서버가 필요하기 때문. 그래서 우선 이미지를 만들어 push하고 push한 이미지를 구동한 후에 테스트를 이어서 진행하고자 하였다. 해당 단계를 설명하기 전에, 구성하였던 CI/CD의 전반적인 과정은 다음과 같다. 1. JUnit 테스트 2. Jacoco 테스트 3. 테스트용 Docker image 생성 -> 이후 pipeline 일시정지 4. 사용자는 생성된 docker image로 서버를 구동(스크립트 등을 이용해) 5. 테스트 이어서 진행(Gitlab에는 pipeline 일시정지 기능이 있다!) 6. SiteSpeed 테스.. 공감수 0 댓글수 0 2022. 4. 29.
[CI/CD] Gitlab-ci.yml 작성 예제 - Jacoco 이번엔 Jacoco. Jacoco또한 Java 테스팅 툴로, 앞서 작성한 JUnit의 테스트 코드를 그대로 사용하게 됨 해당 코드를 이용해서 전체 프로그램, 클래스의 커버리지(Coverage) 테스트를 진행할 수 있음 JUnit과 마찬가지로, Gradle 셋팅부터 시작 plugins { id 'java' id 'application' id 'jacoco' // 해당 내용 추가 } jacoco { toolVersion = 'Jacoco의 버전' } jacocoTestReport { reports { // xml.enabled = true // 설정에 따라 xml 혹은 csv로 레포트를 받을 수 있음 csv.enabled // 여기서는 csv로 결과를 받기로 함. 추후 있을 gitlab-ci를 위해 // x.. 공감수 0 댓글수 0 2022. 4. 29.
[CI/CD] Gitlab-ci.yml 작성 예제 - JUnit 본 글에서는 JUnit, Jacoco, Jmeter, SiteSpeed.io를 gitlab-ci.yml에 작성하는 틀을 적어두고자함. JUnit JUnit은 우선 Gradle 환경을 기반으로 설명하고자 함. JUnit은 자바의 유닛 테스트 도구로, gradle에서 해당 플러그인을 지원하고 있음 - build.gradle 파일에 다음과 같은 내용 추가 버전이 달라 작성하는 내용에 약간의 차이가 있을 수 있음 implementation ("junit:junit:{junit버전}") testImplementation ("junit:junit:{junit버전}") 이후, Java Testcase를 직접 작성하고 package test; import static org.junit.Assert.*; import o.. 공감수 0 댓글수 0 2022. 4. 28.
[CI/CD] GitLab CI/CD 적용 시 알아두면 좋은 점 해당 업무를 진행하면서 조사하고 적용한 내용중 잊어먹지 않으면 좋을만한 것을 정리하고자 함. GitLab은 자체적으로 제공하는 GitLab Runner를 통해 CI/CD를 자동화하는 기능을 제공하고 있음 이를 설정하면서 겪은 크가지 두 주의점을 기록해두고자 함 1) Gitlab-Gitlab Runner 연동 시 주의할 점 2) DIND 대신 socket을 이용해 runner 동작시키는 법 GitLab은 해당 레포지토리에 commit이 push될 때 CI를 동작하도록 하며 해당 브랜치가 master 브랜치에 머지될 때 마다 CD 작업을 수행하도록 설정할 수 있음. 일련의 과정들은 앞서 언급된 GitLab Runner를 통해 수행됨 GitLab Runner는 쉽게 말해 GitLab에서 지시한 일을 수행하고 .. 공감수 0 댓글수 0 2022. 4. 28.
[CI/CD] Gitlab-ci.yml 작성 예제 - JMeter 테스트했던 것 중에 가장 마지막이었던 JMeter. JMeter는 백엔드 테스팅 도구로, API테스트를 진행하거나 부하 테스트를 진행하는 등의 동작을 수행할 수 있음. 사용자는 JMeter 프로그램을 이용하여 테스트케이스를 작성할 수 있고, 이를 jmx 라는 형태의 파일로 추출할 수 있음. 여기서는 이 jmx 파일을 사용해야하기에, 테스트케이스를 별도로 생성해주어야 함 jmeter는 다행스럽게도 공식 도커 이미지를 제공함 jmeter: stage: after_sitespeed // jmeter는 제공된 공식 이미지를 사용하고, entrypoint를 초기화하여 사용. // 해당 이미지는 docker run 을 이용하여 테스트를 바로 진행할 수 있도록 설계되어있기에 entrypoint를 덮어씌워야 함 ima.. 공감수 0 댓글수 0 2022. 4. 28.
[CI/CD] Gitlab-ci.yml 작성 예제 - SiteSpeed.io 사실, Gitlab의 경우에는 Premium 버전을 구매해서 사용하게 되면 다양한 플러그인을 제공한다. 그 중 하나가 SiteSpeed.io이지만, 여기서는 무료버전에서 해당 기능을 사용하고자 하는 것이므로 이와 관련된 내용을 적고자 한다. SiteSpeed.io는 특정 사이트에 대해 프론트엔드의 부하테스트(load test)를 수행할 수 있는 툴. gitlab-ci.yml은 다음과 같이 작성할 수 있다. 여기서는 제공되는 플러그인이 아닌, NPM에 등록되어있는 sitespeed.io 패키지를 사용한다 주의할 점은 실제 실행되고 있는 서버가 있어야 한다는 점 sitespeed: stage: after_test // NPM에 등록된 SiteSpeed.io 패키지를 사용하고자 함 image: node:16-.. 공감수 0 댓글수 0 2022. 4. 25.
[CI/CD] CI/CD Java 테스팅 도구 사내에서 JAVA를 이용한 웹 프로젝트가 많아서 관련된 테스팅 도구를 조사한 적이 있다. 조사의 목적은 GitLab CI/CD에 얹어 사용할 수 있는 자동화 테스팅 도구를 찾기 위함이었다. 그 중에서 괜찮다고 생각됐던 것들이나, 실제 사용했던 것들을 간략하게 정리하고자 함 주요 조건에 무료 도구여야함이 있었기에 오픈소스/무료인 도구들만 정리되어있음 1. Jenkins - CI 도구이며 각종 플러그인을 사용해 테스팅도 진행할 수 있음. - 주로 빌드 테스트를 위해 사용되며 다양한 플러그인을 지원함 2. Jmeter - 서버 부하 테스트나 API 테스트를 위해 사용 - HTTP/S, REST, TCP, JDBC 등 다양한 테스트가 진행 가능함 - 직접 테스트 스크립트를 작성하고 프로그램을 실행할 수 있음 -.. 공감수 0 댓글수 0 2022. 4. 14.
[Docker] Docker에서 주로 사용한 명령어 지난 업무들에서 주로 사용한 명령어와 자잘하지만 자꾸 까먹을 수 있는 내용들을 좀 정리하고자 한다. [ 많이 사용했던 명령어들] 사실 이미 잘 정리된게 많기도 많고 필요한건 그때그때 쓰면 되긴하지만 1. docker pull 레포명/이미지명:태그 docker build --tag 레포명/이미지명:태그 경로 docker push 레포명/이미지명:태그 - 이미지 받아오기 - 이미지 빌드하기. 경로는 빌드할 곳의 루트 디렉토리. 보통 . 을 이용해서 현재 경로에서 시작함 - 이미지를 레포지토리에 올리기. - 만약 push하는 곳이 공개된 docker hub인 경우에는 계정명/이미지명:태그 로 빌드하고 push하면 된다 2. docker image ls (docker images) - 받아와 로컬에 설치된 이미.. 공감수 0 댓글수 0 2022. 4. 14.

문의안내

티스토리
로그인
고객센터

티스토리는 카카오에서 사랑을 담아 만듭니다.