카테고리 보관물: DEV

ALFA – AWUS036ACS driver install of Kali Linux (v2024.2)

KALI LINUX에서 ALFA – AWUS036ACS 드라이버 설치하는 방법

현재 Kali Linux 최신 버전 2024.2를 사용 중입니다.

먼저, 클래식 업데이트와 업그레이드부터 시작.

sudo apt update && sudo apt upgrade -y

2. 헤더를 로드하고 다양한 새로운 설정을 구성할 수 있도록 재부팅해 보겠습니다.

reboot

3. 헤더와 드라이버에 필요한 패키지를 설치.

sudo apt install bc mokutil build-essential libelf-dev linux-headers-[uname -r]

4. realtek-rtl88xxau-dkms

sudo apt install realtek-rtl88xxau-dkms

5. 이제 github aircrack-ng에서 필요한 일부 파일을 추출해야 합니다.

(메인 디렉토리에 src와 같은 디렉토리를 생성하여 추가하는 것이 좋습니다.)

mkdir src && cd src

git clone -b v5.6.4.2 https://github.com/aircrack-ng/rtl8812au.git

6. rtl8812au 디렉토리로 cd.

cd rtl*

make

sudo make install

7. 다른 필요한 github 파일을 복제해서 설치.

git clone https://github.com/morrownr/8821au-20210708.git

cd 8821*

sudo ./install-driver.sh

재부팅하면 끝납니다 🙂

/lib/modules/[uname -r]/ -name "88XXau.ko" 를 확인할 수 있습니다.

가상 머신을 사용하는 경우 다음 작업을 잊지 마세요.

(virtualbox의 경우)

VirtualBox 확장팩 설치됨
VirtualBox USB 설정 USB 무선 동글 추가
VirtualBox 네트워크 설정: 브리지 어댑터 > RTL88.. > 모두 허용

How to use Oracle dbms_crypto (crypto package library)

오라클 10g 이상에서 사용할 수 있는 DBMS_CRYPTO 패키지를 이용하여 암호화 하는 방법

DBMS_CRYPTO 패키지 생성

설치 되어 있지 않을 경우 다음의 SQL을 수행해서 패키지를 생성한다.

/$ORACLE_HOME/rdbms/admin/dbmsobtk.sql

/$ORACLE_HOME/rdbms/admin/prvtobtk.plb

두 패키지를 추가하는 방법..

A. 오라클 서버에 sysdba으로 접속.

>sqlplus “/ as sysdba”

B. ‘dbmsobtk.sql’ 파일 실행.

리눅스 : @$ORACLE_HOME/rdbms/admin/dbmsobtk.sql;
윈도우 : @%ORACLE_HOME%/rdbms/admin/dbmsobtk.sql;

C. ‘prvtobtk.plb’ 파일 실행.

리눅스 : @$ORACLE_HOME/rdbms/admin/prvtobtk.plb;
윈도우 : @%ORACLE_HOME%/rdbms/admin/prvtobtk.plb;

D. 추가 후 시스템 계정으로만 사용 가능하기 때문에 권한 변경.

이 경우 모두다 실행 가능하도록 하였지만 필요하다면 특정 계정에만 실행권한 주면됨.

grant execute on dbms_crypto to public;

grant execute on dbms_obfuscation_toolkit to public;

# 참고) 콘솔에서 실행 전체 과정.

>sqlplus “/ as sysdba”

SQL>

SQL> @/oracle/rdbms/admin/dbmsobtk.sql

(중간 생략)

No errors.

Synonym created.

SQL> @/oracle/rdbms/admin/prvtobtk.plb

(중간 생략)

Package body created.

No errors.

SQL> grant execute on dbms_crypto to public;

Grant succeeded.

SQL> grant execute on dbms_obfuscation_toolkit to public;

Grant succeeded.

SYS유저에서 사용할 패키지를 생성 함.

테스트에서 사용 할 암호 키 값은 ‘12345678‘을 사용한다.

DOWNLOAD SAMPLE SCRIPT : CRYPTO_PACKAGE_CREATE_SCRIPT

CREATE OR REPLACE PACKAGE PKG_CRYPTO
IS
FUNCTION ENCRYPT(INPUT_STRING IN VARCHAR2, KEY_DATA IN VARCHAR2 := ‘12345678’)RETURN RAW;
FUNCTION DECRYPT(INPUT_STRING IN VARCHAR2, KEY_DATA IN VARCHAR2 := ‘12345678’)RETURN VARCHAR2;
END;

CREATE OR REPLACE PACKAGE BODY PKG_CRYPTO
IS
— 에러 발생시에 error code 와 message 를 받기 위한 변수 지정.
SQLERRMSG VARCHAR2(255) ;
SQLERRCDE NUMBER;
— 암호화 함수 선언 key_data 는 입력하지 않을 시에 default 로 12345678 로 지정됨.FUNCTION ENCRYPT(INPUT_STRING IN VARCHAR2
, KEY_DATA IN VARCHAR2 := ‘12345678’
)
RETURN RAW
IS
KEY_DATA_RAW RAW(4000) ;
CONVERTED_RAW RAW(4000) ;
ENCRYPTED_RAW RAW(4000) ;
BEGIN
— 들어온 data 와 암호키를 각각 RAW 로 변환한다.
CONVERTED_RAW := UTL_I18N.STRING_TO_RAW(INPUT_STRING, ‘AL32UTF8’) ;
KEY_DATA_RAW := UTL_I18N.STRING_TO_RAW(KEY_DATA, ‘AL32UTF8’) ;
— DBMS_PKG_CRYPTO.ENCRYPT 로 암호화 하여 encrypted_raw 에 저장.
ENCRYPTED_RAW := DBMS_CRYPTO.ENCRYPT(SRC => CONVERTED_RAW,
— typ 부분만 변경하면 원하는 알고리즘을 사용할 수 있다.
— 단, key value bype 가 다 다르니 확인해야 한다.
TYP => DBMS_CRYPTO.DES_CBC_PKCS5, KEY => KEY_DATA_RAW, IV => NULL) ;
RETURN ENCRYPTED_RAW;
EXCEPTION
WHEN OTHERS THEN
RETURN INPUT_STRING;
END ENCRYPT;FUNCTION DECRYPT(INPUT_STRING IN VARCHAR2
, KEY_DATA IN VARCHAR2 := ‘12345678’
)
RETURN VARCHAR2
IS
CONVERTED_STRING VARCHAR2(4000) ;
KEY_DATA_RAW RAW(4000) ;
DECRYPTED_RAW VARCHAR2(4000) ;
BEGIN
KEY_DATA_RAW := UTL_I18N.STRING_TO_RAW(KEY_DATA, ‘AL32UTF8’) ;
DECRYPTED_RAW := DBMS_CRYPTO.DECRYPT(SRC => INPUT_STRING, TYP => DBMS_CRYPTO.DES_CBC_PKCS5, KEY => KEY_DATA_RAW, IV => NULL) ;
— DBMS_PKG_CRYPTO.DECRYPT 수행 결과 나온 복호화된 raw data 를 varchar2 로 변환하면 끝!
CONVERTED_STRING := UTL_I18N.RAW_TO_CHAR(DECRYPTED_RAW, ‘AL32UTF8’) ;
RETURN CONVERTED_STRING;
EXCEPTION
WHEN OTHERS THEN
RETURN INPUT_STRING;
END DECRYPT;
END;

사용할 유저에게 실행 권한 부여

기본적으로 DBMS_CRYPTO 패키지 권한 만 부여하면 되지만, 혹시 안 될 경우 두 개의 패키지에 대한 사용 권한을 준다.

grant execute on pkg_crypto to USER;

테스트

패키지가 정상적으로 생성되었는지 테스트

SQL> select sys.pkg_crypto.encrypt ( ‘test’ ) from dual ;

A04B686B118AF67B

SQL> select sys.pkg_crypto.decrypt ( ‘A04B686B118AF67B’ ) from dual ;

test

SQL> create table test_crypto (id int , pwd varchar2(64)) ;

SQL> insert into test_crypto values (1, sys.pkg_crypto.encrypt(‘password1’) ) ;

SQL> insert into test_crypto values (2, sys.pkg_crypto.encrypt(‘password2’) ) ;

SQL> commit ;

SQL> select * from test_crypto ;

1 8A65E0E80532B5FADACA597658B8E8E0

2 8A65E0E80532B5FA6635EBCA6EB4D195

SQL> select id , sys.pkg_crypto.decrypt(pwd) from test_crypto ;

1 password1

2 password2

패키지 소스 암호화 (WRAP)

패키지 바디 부분을 SQL 파일로 저장한 후에, 해당 SQL파일을 오라클의 WRAP 명령을 이용하여 소스를 암호화 한다.

암호화된 소스를 이용하여 패키지를 생성한다.

패키지 바디 부분을 pkg_crypto.sql 파일로 만든 후에, WRAP 명령을 이용하여 소스 암호화를 진행 한다.

..\client_1\BIN>wrap iname=pkg_crypto.sql oname=pkg_crypto.plb

PL/SQL Wrapper: Release 19c.0- Production on Wed Sep 14 12:59:27 2019

Processing pkg_crypto.sql to pkg_crypto.plb

pkg_crypto.plb 파일을 실행 시켜도 되고, 메모장으로 열어서 사용하는 툴에 붙여 넣어서 수행 시켜도 됨.

SQL> select text from dba_source where name = ‘PKG_CRYPTO’;

PACKAGE pkg_crypto

FUNCTION encrypt ( input_string IN VARCHAR2 ) RETURN RAW;

FUNCTION decrypt ( input_string IN VARCHAR2 ) RETURN VARCHAR2;

END pkg_crypto;

— pkg_crypto.plb

PACKAGE BODY pkg_crypto wrapped

a000000

34e

abcd

569 237

ohqkYyNGzuK44ZjD/dc7zE6LBD4wg5VeACDWfC/NR2SlOfdRWqio8BgJ+rTLDeZ0KhuUtwfL

pHsh5UXSmrE5hH7n/MYlulcFuxz+/3JEolt108hdUznBsR865PlC+TBOESlCZ+k6dfP/0AHl

m7ZdffubfOeMEW+6xue2jQP8dS8cEnnuvOBaUG77FS9kmfvhlxjyhQm4lwlnk65byQ4mpm7j

GILd7l4DK2J9rhLoBmcn9GupCftFAI05Ew3eYFuXMfS4NUsCqzdZDLE1ssWoPgFg+nUzSFvF

96FFaMLpCoAYcU9Tq8HdBzHF2Ns/HrqqvzJZx/uPlmo9e4NoSHOonHhr6S2BSS6PXVSXOfeW

dCG489cqwDaf/h2Nxx6WEONFUFoTb7aNG1pvW8Ng5SfDjDYeq4D+lAQA3onCzKeT6/y2hsuA

IJnvdL8FCN3PdeQlz1W8zWexpkBqPyhKvj+RXuuxlTfRnM2voRmdrRch6sSNazdobfnUJOL4

tbN6GdLtMV5ecSORI6U3gkDu9v0wuFojLTjBxLTrCgbIq5AI1x9AOIKC

Apache tika를 사용하여 컨텐츠 구문 분석 RESTFul 서버 설치

Java 로 개발된 contents 를 parsing 하는 라이브러리 및 app 으로 command line 및 GUI 모드로 동작하는 app 와 RESTFul API 로 동작하는 server 가 있습니다.

# 설치

커맨드용 app 는 다음 주소에서 받으면 됩니다.

$ wget http://apache.mirror.cdnetworks.com/tika/tika-app-1.19.jar

standalone 으로 구동하고 RESTFul 로 요청할 수 있는 서버도 있는데 자동화하려면 이게 더 편리하며 아래 주소에서 받으면 됩니다.

$ wget http://apache.mirror.cdnetworks.com/tika/tika-server-1.19.jar

서버로 구동할 경우 처리 결과를 DB 에 남기려면 SQLite JDBC 가 필요하며 아래 라이브러리를 다운받아서 동일한 폴더에 위치시키면 됩니다.

$ wget http://central.maven.org/maven2/org/xerial/sqlite-jdbc/3.23.1/sqlite-jdbc-3.23.1.jar

# 실행

실행은 java -jar 옵션으로 아래처럼 실행하면 됩니다.

App

$ java -jar tika-app-1.19.jar

Server

$ java -jar tika-server-1.19.jar

SQLite JDBC 적용하려면 -cp 옵션을 추가합니다.

$ java -cp . -jar tika-server-1.19.jar

기본 포트는 9998 이며 다른 포트(Ex: 1234)로 구동할 경우 아래와 같이 -p 옵션을 추가합니다.

$ java -cp . -jar tika-server-1.19.jar  -h 0.0.0.0 -p 1234

# 서버 정보

서버로 구동했으면 REST API 로 여러 가지 요청을 할 수 있습니다.

version 확인

$ curl localhost:9998/version

Apache Tika 1.19

detector 확인

$ curl localhost:9998/detectors

# 지원하는 mime type 확인

$ curl localhost:9998/mime-types

# 컨텐츠 parsing

meta 분석

$ curl -T a.pdf localhost:9998/meta

특정 필드가 필요할 경우 url 에 필드명 명시하며 아래는 저자 필드만 추출합니다.

$ curl -T a.pdf localhost:9998/meta/Author

PDF 렌더링 속도를 빠르게 하려면 JDK 8 을 사용하고 JVM 구동시 아래 옵션 추가합니다.

-Dsun.java2d.cmm=sun.java2d.cmm.kcms.KcmsServiceProvider

# 원하는 형식으로 출력

기존 출력은 text/csv 이며 Accept 헤더에 원하는 포맷을 설정해서 호출하면 됩니다.

XML

$ curl -T a.pdf -H "Accept: application/rdf+xml" localhost:9998/meta

아래는 json 형식으로 결과물을 전달 받습니다.

$ curl -T a.pdf -H "Accept: application/json" localhost:9998/meta

JSON 일 경우 개행을 안 해서 보기가 힘드니 jq 로 포맷팅 하면 결과물이 보기 편해집니다.

$ curl -T a.pdf -H "Accept: application/json" localhost:9998/meta | jq .

Example

$ curl -H "Accept: application/json" localhost:9999/meta -T sample.pdf

 $ curl -H "Accept: text/plain" localhost:9999/tika -T sample.pdf

 $ curl -H "Accept: application/json" localhost:9999/rmeta -T sample.pdf

Docker Root Directory 위치 변경

개발 중인 서버에 접근해보니 루트 디렉토리가 91% 사용 중이었습니다.

(*도커의 루트 디렉토리 증설은 불가피했음.)

초기 설치 시 /var/lib/docker/overlay 디렉토리 경로 그대로 사용

01. 루트 디렉토리 설정 확인하기

docker info | grep Root 명령어로 Docker Root Dir이 /var/lib/docker임을 확인했습니다.

[root@totoli]# docker info | grep Root
 Docker Root Dir: /var/lib/docker

02. 루트 디렉토리 설정 변경하기

도커의 설정은 /etc/docker/daemon.json를 변경하면 됩니다.
json 형식으로 작성하면 되며, data-root 요소를 작성합니다.

[root@totoli]# vi /etc/docker/daemon.json

{
  "data-root": "/docker-data/data"		# 변경하고자 할 디렉토리로 작성합니다.
}

*example mount path : "/docker-data" 
mkdir /docker-data/data
cp -rp /var/lib/docker/* /docker-data/data/

03. 설정 변경 후 도커 재기동하기

[root@totoli]# systemctl restart docker

04. 루트 디렉토리 설정 재확인하기

docker info | grep Root 명령어로 다시 한번 확인합니다.
설정했던 바와 같이 /docker-data/data로 변경됨을 확인할 수 있습니다.

[root@totoli]# docker info | grep Root
 Docker Root Dir: /docker-data/data

/var/lib/docker/~~~에서 /docker-data/data/~~~ 로 변경됨을 확인.

05. 기존 루트 디렉토리 삭제

docker info | grep Root 명령어로 다시 한번 확인합니다.
설정했던 바와 같이 /docker-data/data로 변경됨을 확인할 수 있습니다.

ls /docker-data/data
* 잘 복사된것 확인 후 .

[root@totoli]# rm /var/lib/docker -Rf

ORACLE DB dump backup and recovery (export / import)

오라클에서 데이터베이스나 스키마 별로 데이터를 저장, 백업하거나

다시 복구해야할때, DB Dump를 떠논다고 말한다.

Dump는 간단한 명령어로 쉽게 떠지지만,

반드시 Dump를 저장할 디렉토리를 만들어 지정해줘야한다.

1. 오라클시스템상 디렉토리 만들기.

CREATE DIRECTORY datadump AS 'C:\dump';
GRANT READ, WRITE ON DIRECTORY datadump TO SYSTEM;
GRANT CREATE ANY DIRECTORY TO SYSTEM;

SELECT * FROM DBA_DIRECTORIES;

1. C밑에 물리적인 폴더를 생성하고, (dump라는 이름으로 생성했다)

이후 “CREATE DIRECTORY datadump AS ‘C:\dump'”를 수행하여

데이터 베이스 상에 논리적 디렉토리를 지정해준다. (datadump라는 폴더를 만들었다.)

2. 이후 읽고 쓰기 권한을 부여해주어야 한다.

GRANT READ, WRITE ON DIRECTORY datadump TO SYSTEM
;
GRANT CREATE ANY DIRECTORY TO SYSTEM;

3. 확인

SELECT * FROM DBA_DIRECTORIES; 를 수행하면 만들어졌음을 확인할수있다.

로컬이라면, CMD에서 sqlplus 명령어로 dba로 접속하여 진행해도 무방하다.

cmd> sqlplus / as sysdba

2. export / emport 시작

CMD창에서 반출 명령어를 입력한다. (접속 스키마 id/pw , ip:포트, db풀, 만든 directory정보 확인)

-- expdp 반출
--db full
expdp userid=ECUBE2/ECUBE2@//127.0.0.1:1521/OBZMETA dumpfile= OBZMETA.dmp directory=datadump  full=y logfile=fullexp.log

*localhost 경우 @//127.0.0.1:1521/OBZMETA 생략 가능
--schema (ECUBE2, ECUBEEBM2)
expdp userid=ECUBE2/ECUBE2@//127.0.0.1:1521/OBZMETA  dumpfile=ECUBE2.dmp directory=datadump  schemas=ECUBE2 logfile=fullimp.log

expdp userid=ECUBEEBM2/ECUBEEBM2@//127.0.0.1:1521/OBZMETA  dumpfile=ECUBEEBM2.dmp directory=datadump  schemas=ECUBEEBM2 logfile=fullimp.log

--반입
--db full
expdp userid=ECUBE2/ECUBE2@//127.0.0.1:1521/OBZMETA dumpfile= OBZMETA.dmp directory=datadump  full=y logfile=fullexp.log


--schema (ECUBE2, ECUBEEBM2)
impdp userid=ECUBE2/ECUBE2@//127.0.0.1:1521/OBZMETA  dumpfile=ECUBE2.dmp directory=datadump  schemas=ECUBE2 logfile=fullimp.log

impdp userid=ECUBEEBM2/ECUBEEBM2@//127.0.0.1:1521/OBZMETA  dumpfile=ECUBEEBM2.dmp directory=datadump  schemas=ECUBEEBM2 logfile=fullimp.log

다른 도메인 내 iframe의 세션이 유지가 안될때 ( Same Site )

문 제

A.com 내에 내가만든 B.com/B.jsp 을 iframe 으로 걸었다.

내가 만든 B.com/B.jsp 내의 세션값을 뽑아도 계속 null인 상황이다.

줄곧 크롬으로 테스트 했던터라 IE로 하니까 또 잘된다.

확인한 부분을 정리하면 이렇다.

1. 크롬 개발자 도구로 Response Headers 를 확인 보았다.

2. Set-Cookie 값안에 JSESSIONID 값이 만들어 지는데, 이값이 호출때마다 변경 된다.

자세히 보면 오른쪽에 노란색 느낌표가 떠있고, 마우스를 가져가면, SameSite 관련 부연설명이 나온다.

웹 search를 해보면 SameSite관련 이슈로 A.com -> B.com POST 방식으로

리다이렉트 했을때 기존에 읽어지던 쿠키값을 읽을수 없는케이스가 제일 많은듯 했다.

3. iframe을 걸어놓은 B.com/B.jsp 에서는 session.getAttribute를 통해서 값이 꺼내지지만,

java servlet 레벨에서 아래와 같이 뽑아도 null 값만 나오게 된다.

request.getSession().getAttribute("String");

원인 – Chrome 80 쿠키 SameSite 정책이 변경 되었다.

– 도메인이 서로 다른 사이트 간 이동을 하는 경우 쿠키 전달 불가

– 기본 SameSite를 Lax로 변경

( 2020년 2월4일 크롬 80버전 부터 변경 !! )

SamteSite 쿠키에 대해

SameSite 쿠키의 정책으로 None, Lax, Strict 세 가지 종류를 선택할 수 있고

동작하는 방식이 다르다고 할수 있다.

None:

– SameSite 가 탄생하기 전 쿠키와 동작하는 방식

– None으로 설정된 쿠키의 경우 크로스 사이트 요청의 경우에도 항상 전송

– SameSite를 None으로 설정할 경우 쿠키에 암호화된 HTTPS 연결이 필요함을 나타내는

Secure 속성을 같이 설정해주어야 한다.
– HTTPS 일때만 사용 가능.

Lax:

Strict에 비해 상대적으로 느슨한 정책입니다. Lax로 설정된 경우, 대체로 서드 파티 쿠키는 전송되지 않지만, 몇 가지 예외적인 요청에는 전송 된다.

Strict:

– 가장 보수적인 정책.

– Strict로 설정된 쿠키는 크로스 사이트 요청에는 항상 전송않음.

– 즉, 서드 파티 쿠키는 전송되지 않고, 퍼스트 파티 쿠키만 전송 된다

해 결

결론은 크롬의 쿠키 보안정책이 바뀌어서,

기본이 SameSite의 레벨이 NONE에서 LAX 올라갔으니, 다시 NONE으로 내려주면 된다는 것이다.

중요한점은 HTTPS 일때 사용가능하다.

SameSite 설정시에 None 옵션과 Secure를 함께 주도록되어있는데,

이때 Https일때만 사용이 가능하다고 한다.

즉 B.com 의 도메인은 https 호출이 가능해야 한다.

A.com 의 설정을 건드릴 필요없이 iframe이 걸리는 B.com 쪽에 서버 설정을 수정해야 했다.

나는 앞단에 Apache 서버가 있고, WAS 가 따로 있는 상황이었다.

이럴경우는 apache 웹서버에서 설정을 해줄수 있다.

Apache_HOME / conf / httpd.conf

<IfModule headers_module>
        Header edit Set-Cookie ^(.*)$ $1;SameSite=None;Secure;
</IfModule>

값을 넣어주고 apache 재기동을 했다.

다음부터는 호출시 B.com/b.jsp에서도 세션값에서 정상적으로 값이 꺼내지고

Set-Cookie 값안에 JSESSIONID 값 자체가 유지되는 것을 확인 할수 있었다.

구글 공지

https://blog.chromium.org/2019/10/developers-get-ready-for-new.html

참고자료

https://web.dev/samesite-cookies-explained/

https://chromestatus.com/feature/5088147346030592

http://www.gnujava.com/board/article_view.jsp?board_no=37&article_no=8583

https://velog.io/@jsj3282/%EA%B5%AC%EA%B8%80-Chrome-SameSite-%EC%9D%B4%EC%8A%88

[Kubernetes] Understanding how the Calico CNI works

[Kubernetes] Calico CNI 동작원리 이해하기

Calico란, 컨테이너, 가상 머신 및 기본 호스트 기반 워크로드를 위한 오픈 소스 네트워킹 및 네트워크 보안 솔루션이다.
Kubernetes, OpenShift, Mirantis Kubernetes Engine(MKE), OpenStack 및 베어메탈 서비스를 포함한 광범위한 플랫폼 지원한다.
Calico의 eBPF 데이터 플레인을 사용하든 Linux의 표준 네트워킹 파이프라인을 사용하든 Calico는 진정한 클라우드 네이티브 확장성과 함께 놀랍도록 빠른 성능을 제공한다.
Calico는 공용 클라우드나 온프레미스, 단일 노드 또는 수천 개의 노드 클러스터에서 실행되는지 여부에 관계없이 개발자와 클러스터 운영자에게 일관된 경험과 기능 세트를 제공한다.

구성 요소 아키텍처(링크)

- BGP(Border Gateway Protocol): AS 사이에서 이용되는 라우팅 프로토콜. 대규모 네트워크(수천만의 경로 수)에 대응하도록 설계됐다. 그래서 BGP로 동작하는 라우터는 비교적 고가인 제품이 많다.
- AS(Autonomous System): 하나의 정책을 바탕으로 관리되는 네트워크(자율 시스템)를 말한다. ISP, 엔터프라이즈 기업, 공공기관 같은 조직이 이에 해당하며 인터넷은 이러한 자율 시스템의 집합체이다.여러가지 구성 요소가 많지만, 일단 눈여겨 볼 내용은 Calico가 사용하는 Datastore[1]와 마스터 노드를 포함한 모든 노드들에 존재하는 Calico Pods[2]
  - Felix (필릭스) : 인터페이스 관리, 라우팅 정보 관리, ACL 관리, 상태 체크
  - BIRD (버드): BGP Peer 에 라우팅 정보 전파 및 수신, BGP RR(Route Reflector)
  - Confd : calico global 설정과 BGP 설정 변경 시(트리거) BIRD 에 적용해줌
  - Datastore plugin : calico 설정 정보를 저장하는 곳 – k8s API datastore(kdd) 혹은 etcd 중 선택
  - Calico IPAM plugin : 클러스터 내에서 파드에 할당할 IP 대역
  - calico-kube-controllers : calico 동작 관련 감시(watch)
  - calicoctl : calico 오브젝트를 CRUD 할 수 있다, 즉 datastore 접근 가능

구성 요소 확인하기

데몬셋으로 각 노드에 calico-node 파드가 동작하여, 해당 파드에 bird, felix, confd 등이 동작 + Calico 컨트롤러 파드는 디플로이먼트로 생성
- Calico의 특징은 BGP를 이용해 각 노드에 할당된 Pod 대역의 정보를 전달한다. 즉, 쿠버네티스 서버뿐만 아니라 물리적인 라우터와도 연동이 가능 하다는 뜻이다. (Flannel의 경우 해당 구성 불가)
- Calico Pod 안에서 Bird라고 하는 오픈소스 라우팅 데몬 프로그램이 프로세스로 동작하여 각 Node의 Pod 정보가 전파되는 것이다.
- 이후 Felix라는 컴포넌트가 리눅스 라우터의 라우팅 테이블 및 iptables rule에 전달 받은 정보를 주입하는 형태이다.
- confd는 변경되는 값을 계속 반영할 수 있도록 트리거 하는 역할이다.

Calico 기본 통신 과정 확인하기

calicoctl 설치

리소스 관리를 위해 Calico CLI를 설치 및 구성

마스터 노드 확인

Calico CNI 설치시, 데몬셋이므로 모든 노드에 칼리코 파드가 하나씩 존재하게 된다. (calico-node-*)
칼리코 컨트롤러가 하나 존재하는 것을 확인할 수 있다.
calicoctl ipm show 명령어를 통해, IAPM 정보를 확인할 수 있다. 아래 스크린샷에서는 172.16.0.0/16 대역을 해당 쿠버네티스 클러스터에서 사용할 수 있다는 내용을 알 수 있다.
- IPAM(IP Address Management): 풍부한 사용자 환경을 통해 IP 주소 인프라의 엔드 투 엔드 계획, 배포, 관리 및 모니터링을 지원하는 통합 도구 모음이다.
  IPAM은 네트워크상의 IP 주소 인프라 서버 및 DNS(도메인 이름 시스템) 서버를 자동으로 검색하여 중앙 인터페이스에서 이들 서버를 관리할 수 있다.
- 옵션을 통해 아래와 같이 특정한 노드에 할당 가능한 대역대를 확인할 수도 있음(Block는 각 노드에 할당된 Pod CIDR 정보를 나타냄)
calicoctl node 정보 확인
ippool 정보 확인
파드와 서비스 사용 네트워크 대역 정보 확인

실습 1.

동일 노드 내 파드 간 통신

결론: 동일 노드 내의 파드 간 통신은 내부에서 직접 통신됨

파드 생성 전 노드(k8s-w1)의 기본 상태

노드(k8s-w1)에 파드 2개 생성

아래 내용으로 node1-pod2.yaml 파일 작성 후 파드 생성
파드 생성 전후의 변화를 관찰하기 위해 터미널 하단 추가 탭에watch calicoctl get workloadEndpoint 명령어를 사용하여 모니터링
- calicoctl 명령어로 endpoint 확인: veth 정보도 확인할 수 있음

생성된 파드 정보 확인

네트워크 인터페이스 정보 확인(k8s-w1)

calice#~ 두개 추가된 것을 확인할 수 있음
각각 net ns 0,1로 호스트와 구별되는 것을 확인할 수 있음

네트워크 네임스페이스 확인

아래 2개 PAUSE 컨테이너가 각각 파드별로 생성된 것을 확인할 수 있음
바로 위 스크린샷인 link-netnsid 0, link-netnsid 1과 매칭됨

라우팅 테이블 확인

파드의 IP/32bit 호스트 라우팅 대역이 라우팅 테이블에 추가된 것을 확인할 수 있음

파드간 통신 실행 이해

(위) 마스터 노드에서 Pod1 Shell에 접근하여 Pod2로 Ping 테스트
(아래) 워커 노드(k8s-w1)에서 iptables 필터 테이블에 FORWARD 리스트 중 cali-FORWARD 룰 정보를 필터링해서 watch로 확인
테스트 결과 아래 이미지와 같이 Host iptables에서 FOWRARD라는 테이블의 허용 조건에 따라 정상적으로 통신이 가능한 것을 확인할 수 있다.

파드에서 외부(인터넷)로의 통신

결론: 파드에서 외부(인터넷) 통신 시에는 해당 노드의 네트워크 인터페이스 IP 주소로 MASQUERADE(출발지 IP가 변경) 되어서 외부에 연결됨

파드 배포 전 calico 설정 정보 확인 & 노드에 iptables 확인

마스터 노드에서 아래 내용 확인: natOutgoing의 기본값이 true로 설정되어 있는 것을 확인 할 수 있다. 즉 이 노드에서 외부로 통신할 때 NAT의 MASQUERADE를 사용하겠다는 의미이다.

NAT – MASQUERADE : 조건에 일치하는 패킷의 출발지 주소를 변환하는 것. 내부에서 전달되는 요청의 출발지 주소를 조건에 지정된 인터페이스의 IP로 변환한다.
워커 노드(k8s-w1)에서도 외부로 통신시 MASQUERADE 동작 Rule이 존재하는 것을 확인할 수 있다.

마스터 노드에서 워커 노드(k8s-w1)에 아래 내용의 파드 1개 생성

외부 통신 가능 여부 확인

통신 전, 워커 노드(k8s-w1)에 iptables NAT MASQUERADE 모니터링을 활성화 하면 외부 통신시 pkts값이 증가하는지 확인할 수 있다.
(위) 마스터 노드에서 Pod1 Shell 실행 후, 8.8.8.8로의 통신 성공
(아래) pkts 값이 이전 이미지와 다르게 증가한 것을 확인할 수 있다.

다른 노드에서 파드 간 통신

결론: 다른 노드 환경에서 파드 간 통신시에는 IPIP터널(기본값) 모드를 통해서 이루어진다.
- 각 노드에 파드 네트워크 대역은 Bird에 의해서 BGP로 광고 전파/전달 되며, Felix에 의해서 호스트의 라우팅 테이블에 자동으로 추가/삭제 된다.
- 다른 노드 간의 파드 통신은 tunl0 인터페이스를 통해 IP 헤더에 감싸져서 상대측 노드로 도달 후 tunl0 인터페이스에서 Outer 헤더를 제거하고 내부 파드와 통신한다.

파드 배포 전, 노드에서 BGP에 의해 전달 받은 정보가 호스트 라우팅 테이블에 존재하는지 확인

아래 명령어를 통해 나머지 노드들의 파드 대역을 자신의 호스트 라우팅 테이블에 가지고 있고, 해당 경로는 tunl0 인터페이스로 보내게 된다는 사실을 알 수 있다.

워커 노드(k8s-w1, w2)의 tunl0 정보 확인

터널 인터페이스가 IP에 할당되어 있음
MTU는 1480 (칼리코 사용 시 파드의 인터페이스도 기본 MTU 1480 사용)
현재 TX/RX 카운트는 0 –> 잠시 후, 오버레이 통신시 카운트 값이 증가할 것

마스터 노드에서 워커 노드(k8s-w1, w2) 대상으로 각각 파드 1개씩 생성

calicoctl 명령어를 이용하여 생성된 파드의 엔드포인트 확인

각 노드에서 파드 간 통신을 처리하는 라우팅 정보 확인

k8s-w1(172.16.158.4/32) 노드에서 w2(172.16.184.0) 노드 대역에 통신하려면 192.168.10.102를 거쳐야 한다는 것을 확인할 수 있다.
반대로 w2(172.16.184.1/32) 노드에서 w1(172.16.158.0) 노드 대역에 통신하려면 192.168.10.101를 거쳐야 한다.

다른 노드 파드 간 통신이 어떻게 실행되는지 확인 ⇒ IPIP

(상) Pod2가 속한 노드(k8s-w2)에 tunl0 인터페이스 TX/RX 패킷 카운트 모니터링 세팅
(중) 마스터 노드에서 Pod1 Shell 접속 후, Pod2로 Ping 통신 테스트 준비
(하) Pod1이 속한 노드(k8s-w1)에서 패킷 덤프 세팅: tunl0 – 터널 인터페이스에 파드간 IP 패킷 정보를 확인할 수 있음
결과
- (중) Pod1 –> Pod2로 정상 통신 확인
- (상) tunl0 인터페이스의 TX/RX 패킷 카운트가 각각 10개로 증가
- (하) 실제 통신을 하게 되는 파드 간 IP 패킷 정보 확인
실제로 오버레이 통신을 하고 있는지 확인하기 위해 패킷덤프 명령어를 아래와 같이 수정하여 Ping 통신을 다시 하였고, 결과적으로 IP Outer(파란색 박스) 헤더 정보 안쪽에 Inner(빨간색 박스) 헤더가 1개 더 있음을 확인할 수 있다.

Calico 네트워크 모드

Calico Mode 요약

칼리코는 다양한 네트워크 통신 방법을 제공한다.

IPIP 모드

파드 간 통신이 노드와 노드 구간에서는 IPIP 인캡슐레이션을 통해 이루어진다.
단, Azure 네트워크에서는 IPIP 통신이 불가능하기 때문에 대신 VXLAN 모드를 사용한다고 한다.

Direct 모드

파드 통신 패킷이 출발지 노드의 라우팅 정보를 보고 목적지 노드로 원본 패킷 그대로 전달된다.
단, 클라우드 사업자 네트워크 사용 시, NIC에 매칭되지 않는 IP 패킷은 차단되니 NIC의 Source/Destination Check 기능을 Disable해야 정상 통신 가능 (AWS 문서 링크)

BGP 연동

Kubernetes 클러스터 내부 네트워크와 IDC 내부망 네트워크 간 직접 라우팅도 가능

VXLAN 모드

파드 간 통신이 노드와 노드 구간에서는 VXLAN 인캡슐레이션을 통해서 이루어진다.
다른 노드 간의 파드 통신은 vxlan 인터페이스를 통해 L2 프레임이 UDP – VXLAN에 감싸져 상대 노드로 도달 후 vxlan 인터페이스에서 Outer헤더를 제거하고 내부의 파드와 통신하게 된다.
BGP 미사용, VXLAN L3 라우팅을 통해서 동작한다.
UDP를 사용하므로 Azure 네트워크에서도 사용 가능하다.

Pod 패킷 암호화(네트워크 레벨)

Calico의 다양한 네트워크 모드 환경 위에서 WireGuard 터널을 자동 생성 및 파드 트래픽을 암호화하여 노드 간 전달한다.
Yaml 파일에 간단하게 추가하는 것만으로도 네트워크 레벨의 패킷 암호화를 설정할 수 있다.

WireGuard는 구닥다리 IPsec 및 OpenVPN의 대항마로 등장한 open source VPN project이며 작년, Linux 5.6 커널에 WireGuard 1.0.0 기본 패키지로 탑재되었다.

정말 간결한 코드 구조와 빠른 성능 (모든 것이 kernel에서 동작하고, 주요 암호 알고리즘에 대해서 병렬처리하므로써 빠른 속도를 자랑함)

실습 2. WireGuard

WireGuard 설정

모든 노드에 WireGuard를 설치(apt install wireguard -y)하고, Enabled 설정
현재 노드에 존재하는 Wireguard 퍼블릭 키 확인
wireguard.cali 인터페이스 정보 확인
wg로 시작하는 명령어를 사용하여 wireguard.cali 설정 확인: 노드 별로 각각의 상대방 Peer의 IP와 퍼블릭 키를 확인할 수 있음

동작 확인

아래 내용으로 파드 생성
(상) 파드가 생성된 노드의 eth0(enp0s8)에서 패킷 덤프 모니터링 세팅
(하) 생성한 파드 Shell 접속 후 Ping 통신 준비
(하) Pod2 IP 확인
(중) Pod1 –> Pod2 Ping 정상 통신
(상) 51820 포트 패킷 덤프 내용 확인

3-Tier container environment configuration using Kubernetes (NginX/Tomcat/MySQL)

쿠버네티스를 활용한 3-Tier 컨테이너 환경 구성을 해보고자 한다. 구성은 도커와 동일하게 아래와 같이 간다.

3-Tier container environment configuration using Docker(NginX/Tomcat/MySQL)

이번에는 구성 시에 1-Container에 WEB/WAS/DB Pod를 각각 띄울 예정이다.

동일한 컨테이너에서 기동하기 때문에 서로에 대한 IP는 변하지 않을 것이고 IP Address는 localhost로 설정해주어야 한다.

그렇기 때문에!!

– WEB-WAS 사이의 연동 설정에서 IP를 localhost로 변경

– WAS-DB 사이의 연동 설정(어플리케이션 부분)에서 DB IP를 localhost로 변경

해주어야한다.. 그렇다면 이미지 부터 다시 말아보자.

1. WEB 구성

1-1. NginX의 WAS 연동 설정 파일에서 IP Address를 localhost로 변경 후 다시 이미지 생성

> $ vi /root/nginx-for-petclinic/nginx/conf

17 http {
18     upstream was-list {
19         #server tomcat-petclinic:8080;
20         server localhost:8080;
21     }
22
23     include       mime.types;
24     default_type  application/octet-stream;

1-2. Dockerfile을 이용하여 이미지 생성

root@master:~/nginx-for-petclinic# pwd
/root/nginx-for-petclinic
root@master:~/nginx-for-petclinic# docker build -t nginx-petclinic:2.0 .

# 이미지 생성 후, 확인

root@master:~/nginx-for-petclinic# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx-petclinic 2.0 1f34b3ccac6d 5 seconds ago 133MB

1-3. 이미지를 Dockerhub에 저장

> 내가 생성한 이미지를 이따 yaml파일에서 로드할 수 있도록..

root@master:~# docker tag nginx-petclinic:2.0 ghkd5216/nginx-petclinic:2.0
root@master:~# docker push ghkd5216/nginx-petclinic:2.0

The push refers to repository [docker.io/ghkd5216/nginx-petclinic]
52efdeec58ec: Pushed
201e7ba1790a: Pushed
9959a332cf6e: Layer already exists
f7e00b807643: Layer already exists
f8e880dfc4ef: Layer already exists
788e89a4d186: Layer already exists
43f4e41372e4: Layer already exists
e81bff2725db: Layer already exists
2.0: digest: sha256:15cf195c6e6575d744fa0eb07b429d0db3d99f61

2. WAS 구성

2-1. WAS에서는 AP쪽에 DB 설정이 있기 때문에 소스 빌드 및 해당 소스가 디플로이된 이미지를 다시 생성해야 한다.

> $vi /root/spring-framework-for-petclinic/pom.xml

> 515번 라인과 같이 localhost로 변경해주면 된다.

509             <id>MySQL</id>
510             <properties>
511                 <db.script>mysql</db.script>
512                 <jpa.database>MYSQL</jpa.database>
513                 <jdbc.driverClassName>com.mysql.jdbc.Driver</jdbc.driverClassName>
514 <!–<jdbc.url>jdbc:mysql://mysql-petclinic:3306/petclinic?useUnicode=true</jdbc.url>–>
515                 <jdbc.url>jdbc:mysql://localhost:3306/petclinic?useUnicode=true</jdbc.url>
516                 <jdbc.username>root</jdbc.username>
517                 <jdbc.password>petclinic</jdbc.password>
518             </properties>

2-2. 소스 빌드를 위한 자바 변경

> 자바 버전이 1.8이 되도록 수정

root@master:~/spring-framework-for-petclinic# sudo update-java-alternatives –jre-headless –jre –set java-1.8.0-openjdk-amd64

root@master:~/spring-framework-for-petclinic# java -version
openjdk version “1.8.0_292”
OpenJDK Runtime Environment (build 1.8.0_292-8u292-b10-0ubuntu1~20.04-b10)
OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)

2-3. 소스 빌드

> 소스를 빌드하고 나면, 현 디렉토리에 target 안에 petclinic.war라는 소스 파일이 빌드되어 있을 것이다.

root@master:~/spring-framework-for-petclinic# mvn clean package -Dmaven.test.skip=true -P MySQL

…(중략)

[INFO] ————————————————————————
[INFO] BUILD SUCCESS
[INFO] ————————————————————————
[INFO] Total time: 13.144 s
[INFO] Finished at: 2021-11-16T18:04:01+09:00
[INFO] ————————————————————————

2-4. WAS 이미지 생성

> 이제 만든 소스를 활용하여 tomcat 이미지를 만들어보도록 하자.

우선 이미지 생성을 위해 Dockerfile을 생성하고 위에서 만들었던 petclinic.war 파일을 Dockerfile 디렉토리에 위치시킨다.

root@master:/home/dockerfile/petclinic# pwd
/home/dockerfile/petclinic
root@master:/home/dockerfile/petclinic# ls -arlt
total 40644
drwxr-xr-x 5 root root     4096 11월  7 14:06 ..
-rw-r–r– 1 root root 41605349 11월  7 14:06 petclinic.war
-rw-r–r– 1 root root       64 11월  7 14:06 Dockerfile
drwxr-xr-x 2 root root     4096 11월  7 14:06 .

==================================================
하기는 Dockerfile 내용이다.
==================================================
root@master:/home/dockerfile/petclinic# cat Dockerfile
From tomcat:8-jre8
ADD petclinic.war /usr/local/tomcat/webapps/

위와 같이 준비가 되었다면 이제 해당 위치에서 이미지 빌드를 하면 된다.

커맨드는 아래와 같다.

root@master:/home/dockerfile/petclinic# docker build -t tomcat-petclinic:2.0 .
Sending build context to Docker daemon 41.61MB
Step 1/2 : From tomcat:8-jre8
—> cff25871f024
Step 2/2 : ADD petclinic.war /usr/local/tomcat/webapps/
—> 1c6d007012d5
Successfully built 1c6d007012d5
Successfully tagged tomcat-petclinic:2.0

2-5. 이미지를 Dockerhub에 저장

> 내가 생성한 이미지를 이따 yaml파일에서 로드할 수 있도록..

root@master:~# docker tag tomcat-petclinic:2.0 ghkd5216/tomcat-petclinic:2.0
root@master:~# docker push ghkd5216/tomcat-petclinic:2.0
The push refers to repository [docker.io/ghkd5216/tomcat-petclinic]
3fe16f1fe077: Pushed
7a1149e8d0d8: Layer already exists
f3d15ade5c54: Layer already exists
80ac7083a323: Layer already exists
01de28a83f3f: Layer already exists
74a293db1084: Layer already exists
68c1e7509c65: Layer already exists
6ccd0e6bdf7a: Layer already exists
9f9f651e9303: Layer already exists
0b3c02b5d746: Layer already exists
62a747bf1719: Layer already exists
2.0: digest: sha256:7ee8909691df00b211aa42f1605062019422b0d93d52053d4ad01034390e04a7 size: 2631

3. YAML 파일 생성

이제 이미지도 준비되었고, yaml 파일만 생성하여 기동해보면 된다.
도커와는 다르게 쿠버네티스의 경우에는 쿠버네티스 클러스터 내에서 동작하기 때문에 생성된 컨테이너의 IP 또한 클러스터 내의 CNI 네트워크 대역으로 할당된다.

그렇기 때문에 외부에서 해당 컨테이너에 접근하여 서비스를 호출하려면 Service를 통해 가능하다. AWS나 GCP같은 Public Cloud의 경우에는 Service에서 LoadBalnancer를 제공하여 외부로 노출할 IP를 할당 받지만, 우리가 테스트하는 방식과 같이 Baremetal(On-Premise) 환경에서는 LoadBalancer 기능이 없다. 그래서 LoadBalancer타입을 지원하게끔 하기 위해 MetalLB라는 놈을 사용해주어야 한다.

먼저 metalb을 설치해보면 아래와 같다.

root@master:~/yaml# kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.8.3/manifests/metallb.yaml

=================================
metallb.yaml 파일을 이용하여 파드와 기타 등등의 서비스를 실행한다.
이후, metallb-system 네임스페이스에 있는 리소스들을 조회해본다.
=================================

root@master:~/yaml# kc get all -n metallb-system

NAME                              READY   STATUS    RESTARTS   AGE
pod/controller-675d6c9976-d5k57   1/1     Running   0          9s
pod/speaker-h4l8n                 1/1     Running   0          9s
pod/speaker-rm54l                 1/1     Running   0          9s

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/speaker 2 2 2 2 2 beta.kubernetes.io/os=linux 9s

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/controller 1/1 1 1 9s

NAME DESIRED CURRENT READY AGE
replicaset.apps/controller-675d6c9976 1 1 1 9s

이제 3-Tier환경의 컨테이너를 생성할 차례다.

yaml 파일의 경우 아래와 같다.

모든 항목들을 세세히 설명할 수는 없고 하나씩 찾아보면 기본적인 설정(포트/환경변수)만 되어있음을 볼 수 있다.

이 글에서는 가볍게 구성해보는 것이기 때문에 다음 글에서 좀 더 yaml 문법이나 파라미터 값을 공부해보아야 겠다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: petclinic-deployment
  namespace: default
  labels:
    app: petclinic-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
       app: petclinic-app
  template:
    metadata:
      labels:
        app: petclinic-app
    spec:
      containers:
      - image: mysql:5.7.8
        imagePullPolicy: Always
        name: mysql-petclinic
        ports:
        - containerPort: 3306
          protocol: TCP
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: petclinic
        - name: MYSQL_DATABASE
          value: petclinic
      - image: docker.io/ghkd5216/nginx-petclinic:2.0
        imagePullPolicy: Always
        name: nginx-petclinic
        ports:
        - containerPort: 80
          protocol: TCP
      - image: docker.io/ghkd5216/tomcat-petclinic:2.0
        imagePullPolicy: Always
        name: tomcat-petclinic
        env:
        - name: JAVA_OPTS
          value: "-Xms512m -Xmx512m"
        ports:
        - containerPort: 8080
          protocol: TCP
      restartPolicy: Always

---

apiVersion: v1
kind: Service
metadata:
  name: petclinic-svc
spec:
  type: LoadBalancer
  selector:
    app: petclinic-app
  ports:
    - port: 80
      protocol: TCP
      targetPort: 80


---

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.1.240-192.168.1.250

> 제일 하단에 metallb 관련 설정을 보면 addresses 범위 안에서 외부로 노출할 ExternalIP 대역을 설정할 수 있다.

이제 만든 yaml 파일을 실행하여 보자!!

4. Kubernetes를 통한 컨테이너 배포

root@master:~/yaml# kc apply -f petclinic-app.yaml
deployment.apps/petclinic-deployment created
service/petclinic-svc created
configmap/config created

root@master:~/yaml# kc get all
NAME READY STATUS RESTARTS AGE
pod/petclinic-deployment-86dc87794d-j69mm 3/3 Running 0 24s

NAME                    TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)        AGE
service/kubernetes      ClusterIP      10.96.0.1        <none>           443/TCP        13d
service/petclinic-svc   LoadBalancer   10.109.251.153   192.168.56.240   80:30560/TCP   24s

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/petclinic-deployment 1/1 1 1 24s

NAME DESIRED CURRENT READY AGE
replicaset.apps/petclinic-deployment-86dc87794d 1 1 1 24s

> 위와 같이 LoadBalancer 타입의 Service가 생성되어 External-IP를 할당하여 외부로 노출하는 것을 볼 수 있다.

이제 모든 준비가 끝났다.

실제로 외부의 웹 브라우저에서 클라이언트 입장으로 서비스를 호출해보자. 호출 url은 EXTERNAL_IP:[LB PORT]/petclinic 이다.

나의 경우에는 http://192.168.56.240:80/petclinic/으로 호출하면 된다.

5. 서비스 호출

> 외부 노출 IP로 정상적으로 접근 가능하다. 몇 가지 업무 테스트를 해보면,

정상적으로 데이터가 DB에 저장되는 것을 볼 수 있다.

3-Tier container environment configuration using Docker(NginX/Tomcat/MySQL)

이번 글에서는 Docker를 사용하여 간단한 3-Tier 컨테이너 환경을 구성해보고자 한다.

– WEB = NginX

– WAS = Tomcat

– DB = MySQL

구성은 WAS -> WEB -> DB 순으로 하도록 한다.

우선, WAS 부터 구성해보도록 하자.

1. WAS 구성

1-1. Github에 올라가 있는 어플리케이션 소스 다운로드

> 소스를 다운받을 디렉토리 생성 후 Git 저장소에서 소스를 Pull 한다.

root@master:~# mkdir -p /home/src
root@master:~# cd /home/src
root@master:/home/src#

root@master:/home/src# git clone https://github.com/Hwang-sangyeon/spring-framework-for-petclinic.git
Cloning into ‘spring-framework-for-petclinic’…
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 4 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), 1.89 MiB | 4.96 MiB/s, done.

1-2. JDK와 Maven 설치

> 소스를 컴파일 하기 위해 OpenJDK와 Maven을 설치한다.

root@master:~# sudo apt-get install openjdk-8-jdk maven

(중략)
…
update-alternatives: using /usr/lib/jvm/java-11-openjdk-amd64/bin/unpack200 to provide /usr/bin/unpack200 (unpack200) in auto mode
update-alternatives: using /usr/lib/jvm/java-11-openjdk-amd64/lib/jexec to provide /usr/bin/jexec (jexec) in auto mode
Setting up libxdmcp-dev:amd64 (1:1.1.3-0ubuntu1) …
Setting up x11proto-core-dev (2019.2-1ubuntu1) …
Setting up libxcb1-dev:amd64 (1.14-2) …
Setting up libx11-dev:amd64 (2:1.6.9-2ubuntu1.2) …
Setting up libxt-dev:amd64 (1:1.1.5-1) …

1-3. JAVA_HOME 설정

> 현재 java -version으로 버전 확인 시 설치한 자바로 설정되어 있지 않기 때문에 아래와 같이 변경이 필요하다.

root@master:/home/src# sudo update-java-alternatives –list
java-1.11.0-openjdk-amd64 1111 /usr/lib/jvm/java-1.11.0-openjdk-amd64
java-1.8.0-openjdk-amd64 1081 /usr/lib/jvm/java-1.8.0-openjdk-amd64
root@master:/home/src#
root@master:/home/src#
root@master:~# sudo update-java-alternatives –jre-headless –jre –set java-1.8.0-openjdk-amd64

root@master:/home/src# java -version
openjdk version “1.8.0_292”
OpenJDK Runtime Environment (build 1.8.0_292-8u292-b10-0ubuntu1~20.04-b10)
OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)

1-4. 소스 Build

> 이제 소스와 컴파일 할 JDK와 maven도 준비되었기 때문에 Compile을 해보도록 하자

소스 경로에 들어가 압축을 풀고 아래와 같이 빌드를 진행해준다.

빌드 전에 잠시 소스 수정이 필요하다.
pom.xml에 mysql 연동 부분에 localhost:3306을 mysql-petclinic:3306으로 수정하자.
was와 db가 다른 컨테이너로 기동되기 때문에 localhost를 인식할 수 없다.
그러나 mysql-petclinic은 컨테이너 명으로 link가 걸려 통신이 가능하다..

root@master:/home/src/spring-framework-for-petclinic/spring-framework-for-petclinic# mvn clean package -Dmaven.test.skip=true -P MySQL

…(중략)

[INFO] ————————————————————————
[INFO] BUILD SUCCESS
[INFO] ————————————————————————
[INFO] Total time: 16.802 s
[INFO] Finished at: 2021-11-07T13:54:37+09:00
[INFO] ————————————————————————

=========================================================================
빌드를 하고 나면, 소스 경로 하위의 target 디렉토리에 petclinic.war 소스 파일이 생성된다.

root@master:/home/src/spring-framework-for-petclinic/spring-framework-for-petclinic/target# ls -arlt|grep petclinic.war
-rw-r–r– 1 root root 41605349 11월 7 13:54 petclinic.war

1-5. WAS 이미지 생성

> 이제 만든 소스를 활용하여 tomcat 이미지를 만들어보도록 하자.

우선 이미지 생성을 위해 Dockerfile을 생성하고 이전에 만들었던 petclinic.war 파일을 같은 디렉토리에 위치시킨다.

하기는 Dockerfile 내용이다.
root@master:/home/dockerfile/petclinic# cat Dockerfile
From tomcat:8-jre8
ADD petclinic.war /usr/local/tomcat/webapps/

위와 같이 준비가 되었다면 이제 해당 위치에서 이미지 빌드를 하면 된다.

커맨드는 아래와 같다.

root@master:~/docker/tomcat-test# docker build -t tomcat-petclinic .
Sending build context to Docker daemon 41.61MB
Step 1/2 : From tomcat:8-jre8
8-jre8: Pulling from library/tomcat
bb7d5a84853b: Pull complete
f02b617c6a8c: Pull complete
d32e17419b7e: Pull complete
ab18cfab55f9: Pull complete
793716e93ecb: Pull complete
3b9b14f7678b: Pull complete
4dc2d594b57d: Pull complete
3f275ee15a3d: Pull complete
15b0db619216: Pull complete
c0aa838e7a3a: Pull complete
Digest: sha256:47165dabe7c092c61ef2726a7fdc70dda0ce9dea07ca68bda0aea6ecfaba2873
Status: Downloaded newer image for tomcat:8-jre8
—> cff25871f024
Step 2/2 : ADD petclinic.war /usr/local/tomcat/webapps/
—> f27039d77fc4
Successfully built f27039d77fc4
Successfully tagged tomcat-petclinic:latest

2. WEB 구성

2-1. NginX 리소스 다운로드

> Git에 올라가 있는 NginX 리소스를 다운받는다.

root@master:/home/src# git clone https://github.com/Hwang-sangyeon/nginx-for-petclinic.git
Cloning into ‘nginx-for-petclinic’…

리소스 다운로드 후,

nginx.conf 파일에서 was 연동 포트 확인 및 nginx listen-port를 확인한다.

2-2. 이미지 생성

> Dockerfile이 있는 디렉토리에서 이미지를 빌드한다.

root@master:/home/src/nginx-for-petclinic/nginx-for-petclinic# docker build -t nginx-petclinic .
Sending build context to Docker daemon 6.656kB

2-3. WEB/WAS 이미지 확인

root@master:/home/src/nginx-for-petclinic/nginx-for-petclinic# docker images|grep petclinic
nginx-petclinic latest 952aff9083ee 19 seconds ago 133MB
tomcat-petclinic latest 39e56a91e5e7 9 minutes ago 334MB

3. 컨테이너 기동

이제부터는 필요한 이미지가 준비되었기 때문에 WEB/WAS/DB 컨테이너를 기동하여 3-Tier를 구성을 해보려고 한다.

여기서 중요한 점은 WAS가 기동되기 전에 (소스 빌드) DB가 먼저 떠있어야 하기 때문에 DB 컨테이너를 반드시 먼저 기동시켜야 한다는 것이다.

3-1. DB 컨테이너 기동

> mysql-petclinic 컨테이너 명으로 mysql 이미지를 바로 받아 컨테이너를 실행한다.

docker run --name mysql-petclinic -e MYSQL_ROOT_PASSWORD=petclinic -e MYSQL_DATABASE=petclinic -p 3306:3306 mysql:5.7.8

Initializing database 이후 docker container ps로 확인

root@master:~# docker container ps | grep mysql
d286f5c59a6c mysql:5.7.8 “/entrypoint.sh mysq…” 57 seconds ago Up 56 seconds 0.0.0.0:3306->3306/tcp, :::3306->3306/tcp mysql-petclinic

3-2. WAS 컨테이너 기동

docker run -it --rm -p 8080:8080 --name tomcat-petclinic --link mysql-petclinic:mysql-petclinic tomcat-petclinic

> tomcat 컨테이너에서 mysql 컨테이너의 ip로 접속할 수 있겠지만, static ip가 아니기 때문에 mysql 컨테이너의 이름으로 접속을 해야 할 필요가 있다. 이럴 경우 link 옵션을 통해 컨테이너를 구동하면 tomcat 컨테이너에서 mysql 컨테이너로 이름으로 접속할 수 있다. link 옵션으로 구동하면 톰캣 컨테이너 안의 /etc/hosts에 링크된 mysql 컨테이너 hostname과 ip가 들어간다.

3-3. WEB 컨테이너 기동

docker run -it --rm -p 80:80 --name nginx-petclinic --link tomcat-petclinic:tomcat-petclinic nginx-petclinic

4. 서비스 호출

192.168.56.200은 VM의 IP

이상 도커를 활용하여 3-Tier 컨테이너 환경을 구성해보았다..

Installing Helm on Ubuntu for Kubernetes

Ubuntu에 Helm을 설치하려면:

1. 다음 명령을 사용하여 최신 버전의 Helm을 다운로드합니다.

wget https://get.helm.sh/helm-v3.4.1-linux-amd64.tar.gz

다운로드가 완료되면 단말기에서 확인 메시지를 출력합니다.

2. 다음으로 Linux tar 명령 을 사용하여 Helm 파일의 압축을 풉니다 .

tar xvf helm-v3.4.1-linux-amd64.tar.gz

출력에는 압축이 풀린 4개의 파일이 표시됩니다.

3. linux-amd64/helm파일을 /usr/local/bin디렉터리로 이동합니다.

sudo mv linux-amd64/helm /usr/local/bin

명령이 올바르게 실행된 경우 출력이 없습니다.

4. 다음 명령을 사용하여 다운로드한 파일을 제거합니다.

rm helm-v3.4.1-linux-amd64.tar.gz

5. linux-amd64다음을 실행하여 공간을 정리할 디렉터리를 제거합니다.

rm -rf linux-amd64

프로세스가 성공적으로 완료되면 출력이 없습니다.

6. 마지막으로 소프트웨어 버전을 확인하여 Helm을 성공적으로 설치했는지 확인합니다.

helm version

터미널은 소프트웨어의 버전 번호와 GitCommit, GitTreeState 및 GoVersion의 릴리스 번호를 인쇄합니다.

수동으로 최신 버젼의 chart 정보를 레파지토리에 갱신 할 수 있습니다.

$ helm repo add stable https://charts.helm.sh/stable
$ helm repo update