tjddus97 님의 블로그

# 테스트 환경

• OS : Oracle Linux Server release 8.6
• JDK : 1.8
• Jboss ver. : jboss-eap-7.4.0
• Jboss Mode : standalone mode
• Nginx ver. : 1.14.1

기본적인 Log 레벨은 설치 시 INFO 레벨로 설정되어 있다.

하지만 로그를 통해 자세히 보고 싶은 부분이 있거나 INFO로 설정을 했음에도 불구하고 Log가 지나치게 많이 쌓여 불가피하게 Log Level을 변경해야 할 때가 있다.

Log Level 정보

• TRACE : 가장 상세한 디버깅 정보
• DEBUG : 디버깅용 정보가 포함
• INFO : 애플리케이션 상태를 나타내는 일반적인 정보 포함
• WARN : 주의가 필요한 상황에 대한 정보 포함
• ERROR : 오류 발싱 시 사용
• FATAL : 심각한 오류에 대한 정보 포함

가장 밑에 작성한 FATAL이 가정 내용이 적게 기록되며 가장 위에 작성한 TRACE이 가장 내용이 많이 기록된다.

Log Level 변경 방법

1. Jboss Admin Console을 통해 변경

Jboss 관리 콘솔에 로그인 후 Configuration -> Subsystems -> Logging 메뉴 클릭

Edit 버튼을 클릭 후 원하는 Log Level로 설정을 변경한 후 저장 및 Jboss 재 기동하여 확인

2. 설정 파일 변경

logging.properties와 standalone.xml 파일의 내용을 변경 후 저장 및 재 기동

해당 파일들은 [JBOSS_STANDALONE_HOME_DIR]/configuration 경로에 위치해 있다.

- logging.properties

파일 상단에 logger.level 부분을 수정

- standalone.xml

변경하고자 하는 logger 태그를 검색 후 level name 태그에 설정하고자 하는 로그 레벨을 설정

해당 파일의 해당 부분 설정 후 저장 및 재 기동하여 반영

Jakarta EE는 Java를 이용하여 서버 측 개발을 위한 플랫폼이다.

해당 프로젝트가 2027년 이클립스 재단으로 이관됨에 따라 PC 표준 플랫폼이었던 Java EE를 확장하여 Jakarta EE로 변경되었다.

이름만 변경된 것이 아니라 기존의 패키지 네임스페이스가 javax.*에서 jakarta.*로 변경되었다.

따라서 표준 패키지 구조와 API 호출 방식에 영향을 미칠 수 있으며 기존 Java EE 애플리케이션과의 호환성 문제를 야기할 수 있기 때문에 버전에 대한 확인 및 고민이 필요하다.

주요 변경점

Tomcat 9.x

기존의 javax.* 네임 스페이스를 사용하며 Jakarta EE의 패키지 구조 변경을 포함하지 않기 때문에 Jakarta EE와 호환 되지 않는다.

Tomcat 10.x

Jakarta EE 9를 지원하며 패키지 네임스페이스가 jakarta.*로 변경되었다.

• 기존 Java EE 기반 App을 10.x에서 실행하기 위해선 코드나 라이브러리를 jakarta.* 네임스페이스로 변환해야 한다.
• Java SE 8 이상에서 실행된다.

Tomcat 10.1.x

Jakarta EE 10을 지원하며 Java SE 11 이상이 요구된다.

권장 사항

Tomcat 9.x를 유지할 경우 App의 패키지가 변경되지 않는 이상 현재 쓰고 있는 대로 사용하면 되지만 장기적으로는 Jakarta EE 로 전환을 준비하는 것이 권장된다.

Tomcat 10.x 이상으로 업그레이드를 진행할 예정일 경우 jakarta.*로 패키지 네임스페이스 변경이 필요하다.

Tomcat migration Tool을 사용할 경우 전환 작업을 단순화할 수 있다.

Application을 올려야 하는 WAS는 초기 설치 시 Java version, Application에서 필요로 하는 지원 목록에 대한 고려를 하여 version을 선택 후 설치를 진행해야 한다.

각 Tomcat Version 별 특징과 지원되는 항목에 대해 정리해 보았다.

특징과 지원 환경

EOS 날짜

9.X, 10.1.X, 11.X 을 제외 한 이전 버전에 대한 지원은 모두 종료된 상태이다.

현재 지원 중인 version들 세부 특징

Tomcat 9.X

• Servlet 4.0, JSP 2.3, EL 3.0, WebSocket 1.1, JASPIC 1.1(Java EE 8 플랫폼에서 요구하는 버전) 지원
• HTTP/2 지원
• JSSE 커넥터를 사용하여 TLS 지원을 위한 OpenSSL 사용 지원 추가
• TLS 가상 호스팅(SNI) 지원

Tomcat 10.1.X

• Servlet 6.0, JSP 3.1, EL 5.0, WebSocket 2.1, Authentication 3.0(Jakarta EE 10 플랫폼에 필요한 버전) 지원

Tomcat 11.0.X

• Servlet 6.1, JSP 4.0, EL 6.0, WebSocket 2.2, Authentication 3.1(Jakarta EE 11 플랫폼에 필요한 버전) 지원

참고 문헌

# 테스트 환경

• OS : Oracle Linux Server release 8.6
• JDK : 1.8
• Tomcat ver. : 9.0.89

Tomcat에 애플리케이션을 배포하기 위해서 고려해야 할 사항이 2가지 있다.

1. war 파일명 또는 디렉토리 명

Tomcat에서는 기본적으로 [TOMCAT_ENGINE]/webapps/ROOT 디렉토리를 기본 애플리케이션 경로로 가지고 있다.

따라서 최초에 Tomcat 기동 후 기본 페이지를 호출할 경우 아래와 같이 따로 context 경로 입력 필요 없이 /로 설정이 되어 있다.

여기서 배포를 위해 가져온 .war 파일이나 디렉터리 명을 따로 설정하지 않고 ROOT로 설정할 경우 server.xml 변경점 없이 그대로 사용이 가능하다.

기존의 ROOT dir을 ROOT_old로 변경 후 배포하고자 하는 애플리케이션의 dir 명을 ROOT로 변경하고 재기동 및 호출 시 아래와 같은 결과를 얻을 수 있다.

만약 ROOT 말고 다른 이름으로 설정할 경우 2번을 통해 server.xml을 수정하자.

2. server.xml 수정

[TOMCAT_ENGINE]/conf/server.xml 파일을 vi 편집기로 열어 보게 되면

위와 같이 해당 Host 태그 안에 name, appBase, unpackWARs, autoDeploy 등과 같은 옵션들을 통해 default 설정이 되어 있는 것을 확인할 수 있다.

appBase가 webapps로 설정되어 있어 기본 설정 경로가 /webapps/ROOT 였던 것이다.

만약 다른 context path, ROOT가 아닌 다른 어플리케이션 명을 사용하고 싶다면 아래와 같이 설정 후 재기동 및 호출 테스트를 진행해보자

<Host name="localhost"  appBase="webapps"
              unpackWARs="true" autoDeploy="true">
              <Context path="/test" docBase="test"  reloadable="false" > </Context>

- context path : /test

- 애플리케이션 dir 명 : test

테스트 결과는 다음과 같다.

만약 다른 context path, ROOT가 아닌 다른 어플리케이션 명을 사용하고 어플리케이션 배포 경로도 커스텀 하고 싶다면 아래와 같이 설정 후 재기동 및 호출 테스트를 진행해 보자.

<Host name="localhost"  appBase="/sw/tomcat/apache-tomcat-9.0.89"
              unpackWARs="true" autoDeploy="true">
              <Context path="/test" docBase="test"  reloadable="false" > </Context>

- 애플리케이션 위치 : /sw/tomcat/apache-tomcat-9.0.89

- context path : /test

- 어플리케이션 dir 명 : test

테스트 결과는 다음과 같다.

appBase에 설정한 대로 /sw/tomcat/apache-tomcat-9.0.89 경로에 있는 test 폴더를 어플리케이션 경로로 잘 잡고 있는 것을 확인할 수 있다.

정리를 하자면 다음과 같다.

1. Application war 파일이나 DIR 명을 ROOT로 사용할 경우 

- /webapps 밑에 있는 ROOT 파일을 어플리케이션 war 파일이나 DIR로 변경

- server.xml 변경 X

2. Application war 파일이나 DIR 명을 수정 및 context path 수정할 경우

- /webapps 밑에 Application war 파일이나 DIR 위치시키기

- 해당 파일, DIR명을 server.xml에 태그를 추가하여 정보 입력

<Context path="/test" docBase="test"  reloadable="false" > </Context>

3. Application 배치 경로 수정할 경우

- 원하는 경로에 Application 위치시킨 후 server.xml에서 appBase 정보 변경 입력

<Host name="localhost"  appBase="/sw/tomcat/apache-tomcat-9.0.89"
              unpackWARs="true" autoDeploy="true">

# 테스트 환경

• OS : Oracle Linux Server release 8.6
• JDK : 1.8
• WebLogic ver. : 12cR2

SSL 인증서의 경우 보통은 Application이 적재되어 있는 WAS가 아닌 WEB에 설정을 하지만 가끔가다 WLS에 직접 적용해 달라고 요청 오는 사례가 가끔 있다.

아래의 예시는 JKS 확장자의 SSL keystore를 통해 테스트를 진행했다.

1. 대상 서버의 SSL 수신 포트 사용 체크

WLS console에 접근하여 환경 - 서버 - 대상 서버 - 구성 - 일반 탭에서 SSL 수신 포트 사용 체크

(여기서 주의할 점은 다른 수신 포트들과 SSL 수신 포트가 겹치지 않게 설정을 해야 한다.)

2. 키 저장소 정보 입력

환경 - 서버 - 대상 서버 - 구성 - 키 저장소 탭에서 정보 입력

키 저장소 : 사용자정의 ID 및 Java 표준 보안

사용자정의 ID 키 저장소 : 인증서의 위치를 절대 경로로 입력

사용자정의 ID 키 저장소 유형 : JKS

사용자정의 ID 키 저장소 문장암호 : 해당 인증서 패스워드 입력

사용자정의 ID 키 저장소 문장암호 확인 : 해당 인증서 패스워드 입력

3. 개인 키 별칭 등록

환경 - 서버 - 대상 서버 - 구성 - 키 저장소 탭에서 정보 입력

개인 키 별칭 : 인증서 생성 시 입력하였던 Alias Name 작성

개인 키 비밀번호 구문: 인증서 패스워드 입력

개인 키 비밀번호 구문 확인 : 인증서 패스워드 입력

만약 개인 키 별칭 즉, Alias name을 모른다면 아래의 명령어를 통해 찾아보자

keytool -v -list -keystore [Keystore 파일]

4. TEST

SSL 설정을 완료하였다면 해당 서버를 재기동하고 TEST 해보자.

testM1 instance server의 일반 수신 포트인 8002로 호출한 결과와 SSL 수신 포트인 7002로 호출한 결과 모두 정상적으로 애플리케이션의 테스트 페이지를 보여주고 있다.

WEB / WAS 엔지니어로 프로젝트나 외근을 나가다 보면 많이 듣는 단어들이 있다.

Failover와 Failback

2개의 개념 모두 시스템에 이상이 생긴 경우(정전 작업, 장애 등)를 전재로 한다.

Application이 적재되어 있는 WAS와 Client의 요청을 WAS로 분기해 주는 WEB의 입장에선 장애 상황 자체가 상당히 민감한 상황이기 때문에 더욱 신경을 쓰는 부분일 것이다.

1. Failover

고가용성 시스템을 운영하기 위해서는 장비 1대만으로는 모든 상황을 극복하기 어렵기 때문에 대부분 여러 대의 장비를 두고 시스템을 운영하게 된다.

예를 들어 장비 A, B가 있다고 가정을 하면 여기서 운영 중인 장비를 Active, 예비 시스템 장비를 Standby라고 정의하게 된다.

만약 A 장비에서 문제가 생겨 서비스 운영을 못 하게 되었을 때 Standby 장비인 B로 자동 서비스 전환을 해주는 것이 failover이다.

즉, 한쪽 장비에서 장애가 발생하여 해당 서버를 더 이상 사용하지 못하게 될 경우  다른 예비 시스템으로 자동 전환되는 것이다.

장애 상황에 맞춰 WAS / WEB에서 failover 기능을 좀 더 원활히 도와주는 시스템이 있다.

- WAS Cluster 기능

메인 서버가 중단되어 연결되어 있던 session이 끊기더라도 Cluster member 서버인 다른 서버로 해당 session 정보를 넘겨 Client가 느끼기에서는 session 중단이 없도록 한다. 

- WEB LB 기능

제조사가 제공하는 WEB 제품마다 조금씩의 차이점은 존재하지만 WEB 쪽에서 LB 기능을 통해 한쪽 서버로 부하가 몰리는 현상을 미리 방지하고 연결되어 있는 WAS 서버가 사용 불가능인 경우 연결된 다른 WAS 서버로 요청을 분기시키는 기능을 제공한다.

2. Failback

다양한 이유로 서버에 장애가 발생한 경우 장애가 발생하기 전 시점으로 상태를 되돌리는 것이 failback이다.

장애가 발생하기 전 시점으로 되돌린다는 말이 사실 어렵고 크게 다가올 수 있지만 쉽게 말하자면 동기화해 놓은 데이터와 백업해 놓은 다양한 설정값들을 통해 장애 발생 전 상태로 되돌린다는 것이다.

failback 및 roolback 상황을 대비하여 항상 설정값이 작성된 파일(config 파일)은 주기적인 백업이 필요하다.

CKA는 CNCF에서 주관하는 Kubernetes 시험이다.

CNCF의 Github에서는 각 시험에 대한 curriculum을 제공하고 있다.

시험이 해당 커리큘럼에 따라 출제가 되기 때문에 커리큘럼을 미리 파악하고 있는 것이 중요하다.

위의 CNCF CKA 커리큘럼 문서에 따라 정리한 결과는 다음과 같다.

각 카테고리에 대한 세부 사항은 아래와 같다. (2024년 9월 기준)

Cluster Architecture, Installation & Configuration - 25%

• Manage role based access control
• Use Kybeadm to install a basic cluster
• Manage a highly-available Kubernetes cluster
• Provision underlying infrastructure to deploy a Kubernetes cluster
• Perform a version upgrade on a Kubernetes cluster using Kubeadm
• Implement etcd backup and restore

Workloads & Scheduling - 15%

• Understand deployments and how to perform rolling update and rollbacks
• Use ConfigMaps and Secrets to configure applications
• Know how to scale applications
• Understand the primitives used to create robust, self-healing, application deployments
• Understand how resource limits can affect Pod scheduling
• Awarensess of manifest management and common templating tools

Services & Networking - 20%

• Understand host networking configuration on the cluster nodes
• Understand connectivity between Pods
• Understand ClusterIP, NodePort, LoadBalancer service types and endpoints
• Know how to use Ingress controllers and Ingress resources
• Know how to configure and use coreDNS
• Choose an appropriate container network interface plugin

Storage - 10%

• Understand storage classes, persistent volumes
• Understand volume mode, access modes and reclaim policies for volumes
• Understand persistent volume claims primitive
• Know how to configure applications with persistent storage

Troubleshooting - 30%

• Evaluate cluster and node logging
• Understand how to monitor applications
• Manage container stdout & stderr logs
• Troubleshoot application failure
• Trobuleshoot cluster component failure
• Troubleshoot networking

CKA 준비에 앞서 Kubernetes의 기본적인 architecture에 대해 알아보고자 한다.

위의 work flow에서 크게 3가지로 구분을 하면

1. 사용자가 kubernetes에 명령을 전달하기 위해 사용하는 Console
2. console을 통해 들어온 명령을 해석하고 각 node에 전달하는 Master Server
3. Master Server에서 송신한 명령을 수신하여 알맞게 처리하는 Worker node

각각의 역할에 대해 자세히 알아보고자 한다.

1. Console

commend line을 통해 kubernetes를 사용하고자 하는 사용자가 명령을 전달해 줄 수 있도록 도와주는 장비를 일컫는다.

2. Master Server

Api Server

kubernetes에 들어온 명령들을 총괄 컨트롤 하는 Component이다.

Controller

쉽게 설명하자면 사용자가 설정한 환경을 유지해 주는 Component이다.

ex)

사용자가 console을 통해 nginx pod 2대를 Running 시켜라 라는 명령을 전달하면 Controller는 반드시 2개의 pod를 보장할 수 있도록 work node들을 지켜보고 있는다.

또한 nginx pod 1개가 Shutdown될 경우 etcd와 schduler, kubelet를 통해 다시 1개의 nginx pod를 띄우는 방식으로 무조건 2개의 pod가 띄워져 있는 것을 보장할 수 있도록 한다.

schduler

etcd에 저장되어 있는 각 worker node의 정보를 토대로 어느 worker node에 명령을 받은 pod를 몇 대 띄울 것인지를 판단하여 API Server에 전달하는 역할을 수행한다.

node가 배정되지 않은 새로 생성된 pod를 감지하고 실행할 node를 선택하는 역할을 수행한다.

etcd

각 worker node들의 kubelet에 내장되어 있는 C-Advisor를 통해 <KEY, VALUE> 형태로 worker node의 리소스 값이나 컨테이너 이미지 정보 등과 같은 정보들이 저장되는 저장소이다.

coreDNS

service name과 Cluster IP mapping 정보를 저장한다.

- Cluster IP(End Point) : 하나의 Cluster에 속해있는 모든 node들의 IP 정보가 들어간다.

NIC

Host와 network간 데이터를 송수신할 수 있도록 도와주는 인터페이스

CNI

컨테이너끼리 통신할 수 있도록 지원해주는 컨테이너 네트워크 인터페이스

3. Worker node

kubelet

kubernetes를 설치하게 되면 자동으로 kubelet deamon이 start 하게 된다.

master에서 명령 받은 대로 pod에서 컨테이너가 확실하게 동작하도록 관리를 수행한다.

c-Advisor : docker 엔진 기반 하에 현재 이 시스템이 가지고 있는 하드웨어 리소스의 사용률, 컨테이너 이미지들이 얼마나 다운로드가 되었는지 만약 동작 중인 컨테이너가 있다면 그 컨테이너들은 지금 어떻게 동작 중인지 등 이러한 정보들을 전부 수집하는 모니터링 툴

kube-proxy

각 node에서 실행되는 네트워크 proxy로 node의 네트워크 규칙을 유지 관리 한다.

해당 규칙을 통해 내부 network 세션이나 cluster 바깥에서 pod로 네트워크 통신을 할 수 있도록 해준다.

Container Engine

외부 혹은 내부 레지스트리에서 명령에 해당하는 컨테이너 엔진을 찾고 pull download를 받은 역할을 수행한다.

명령이 수행되는 과정

ex) nginx pod 2개 실행시켜줘~!

1. 사용자가 console 장비에서 kubelet 명령어를 통해 명령을 Master Server로 전달
2. 6443 port를 통해 API Server는 해당 명령을 수신하게 되고 명령을 요청한 user에 대한 권한 확인을 진행
3. ETCD에 저장되어 있는 worker node 1, 2의 정보를 꺼내와서 해당 정보들을 토대로 Schduler가 nginx pod 2대를 어느 node에 배치하면 좋을지 판단을 진행
4. Schduler는 판단 결과 값을 API Server에 전달해 주고 API Server는 해당 정보를 ETCD에 저장
5. API Server는 명령을 각 worker node의 kubelet에 전달
6. 각 worker node의 kubelet은 Container Engine에 해당 명령을 전달
7. Container Engine는 nginx 컨테이너를 외부 혹은 내부 레지스트리에서 Pull Download
8. nginx 컨테이너 pod 실행
9. Controller는 nginx pod 2대가 Running 상태인지 지속적으로 watch