네른

보통 로깅을 위한 아키텍쳐라고 하면 ELK(Elasticsearch, Logstash, Kibana)의 구조를 생각하게 된다. 가장 유명한? 널리 알려진? 로깅/분석 스택이기 때문이다. Kubernetes 환경에서도, Kubernetes 자체의 로그 뿐 아니라 내부의 애플리케이션에 대한 로깅과 매니징이 필요하다. 그래서 사내에서 동작중인 앱에 대해 ELK 스택을 적용하고자 하였으나, CNCF stack을 찾아보니 Logstash보다는 Fluentd를 권장하고 있어 이를 사용하게 되었다. Fluentd에 대해 간단히 설명하자면 다음과 같다 - 오픈소스 기반의 로그 수집기 - HTTP, TCP, File 등 다양한 데이터 소스로부터 로그를 수집해 원하는 곳으로 전달(elasticseardch, s3)할 수 ..

본 글에서 알아볼 내용은, 쿠버네티스에서 환경변수, conf 파일 등을 어떻게하면 효율적으로, 편하게 사용하는지에 대한 내용. 실제 kubernetes를 이용하게 되면, 만약 conf 파일이 Pod 내에 있는 경우 이를 수정할 방법이 마땅치 않거나 매우 복잡. 그래서, 이를 조금 더 쉽게 하는 대표적인 두 리소스가 configMap과 secret. - 환경변수 혹은 설정파일을 일종의 변수로 두고 Pod가 생성될 때(배포될 때) 반영할 수 있도록! - 방법은 크게 두 가지로, 환경변수(env) 혹은 disk mount의 방법 ConfigMap - Key-Value 형태로 데이터를 저장할 수 있음 kind: ConfigMap apiVersion: v1 metadata: name: common-config n..

기존의 서비스들은 가용성을 유지하면서 애플리케이션을 업데이트하기 위해 블루-그린 업데이트 등의 방식을 사용해왔음. kubernetes에서는 이러한 업데이트를 '롤링 업데이트' 방식으로 처리함. - ReplicaSet 단위로 진행되며, 기존 ReplicaSet의 replica 수를 줄임과 동시에 새 ReplicaSet의 replica 수를 늘려서 유지되도록 이러한 과정을 추상화해두고, 이용하기 쉽게 해둔것이 바로 Deployment. 앞서 말했던것과 같이, deployment는 ReplicaSet의 추상화된 개념임을 유의 실제 deployment를 배포한 후, 다음과 같은 명령어로 기존 replicaset을 업데이트 할 수 있다. $ kubectl set image deployment DEPLOYMENT이..

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..

저번 포스트에서는 기본 오브젝트들에 대해 정리함. 이번에는 컨트롤러 - Replication Controller(ReplicaSet), Deployment, StatefulSet, DaemonSet, Job Controller 에 대해 정리하고자 함. Controller? - 쿠버네티스의 오브젝트를 관리해주는 것 Replication Controller (ReplicaSet) - 구 버전의 Replication Controller와 ReplicaSet은 동일. - Kube의 Pod 수를 일정하게 유지되도록 생성하고 관리하는 것이 주 역할. - Kube는 가용성 확보를 위해 동일한 Pod를 여러개 띄우게 되는데, 이를 replica로 묶어서 관리하게 됨 : 즉, 어떤 ReplicaSet의 replica 수..

쿠버네티스는 매번 할때마다 새롭기때문에, 간단하게라도 정리해두고자 함. 매우 간단하게 정리할 예정임! 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는 동..

앞서 실행한 두 테스트 이후에, 우선적으로 이미지를 생성하는 작업을 진행하였다. 이유는 뒤이어 실행할 두 테스트 (SiteSpeed.io / JMeter)가 실제 동작중인 백엔드 서버가 필요하기 때문. 그래서 우선 이미지를 만들어 push하고 push한 이미지를 구동한 후에 테스트를 이어서 진행하고자 하였다. 해당 단계를 설명하기 전에, 구성하였던 CI/CD의 전반적인 과정은 다음과 같다. 1. JUnit 테스트 2. Jacoco 테스트 3. 테스트용 Docker image 생성 -> 이후 pipeline 일시정지 4. 사용자는 생성된 docker image로 서버를 구동(스크립트 등을 이용해) 5. 테스트 이어서 진행(Gitlab에는 pipeline 일시정지 기능이 있다!) 6. SiteSpeed 테스..

이번엔 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..

본 글에서는 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..

해당 업무를 진행하면서 조사하고 적용한 내용중 잊어먹지 않으면 좋을만한 것을 정리하고자 함. GitLab은 자체적으로 제공하는 GitLab Runner를 통해 CI/CD를 자동화하는 기능을 제공하고 있음 이를 설정하면서 겪은 크가지 두 주의점을 기록해두고자 함 1) Gitlab-Gitlab Runner 연동 시 주의할 점 2) DIND 대신 socket을 이용해 runner 동작시키는 법 GitLab은 해당 레포지토리에 commit이 push될 때 CI를 동작하도록 하며 해당 브랜치가 master 브랜치에 머지될 때 마다 CD 작업을 수행하도록 설정할 수 있음. 일련의 과정들은 앞서 언급된 GitLab Runner를 통해 수행됨 GitLab Runner는 쉽게 말해 GitLab에서 지시한 일을 수행하고 ..