강남의 MSP 회사들이 IT를 망치고 있다

강남에 MSP 회사들이 많이 있다. Managed Service Provider 라고, 리셀러 개념이라고 하기에는 좀 애매하지만 그외 비슷한 회사들이라고 보면 된다.

아무래도 많은 회사들이 이 MSP 에 기술지원을 받기를 원한다. 왜냐하면 트렌드 자체가 그렇게 흘러가고 있고 이들에 대한 수요가 많다보니 MSP 에 대한 기대가 있는 것이다. 문제는 이러한 회사들이 썩 좋은 방법으로 사업을 영위하고 있지 않다는데 있다.

위험의 외주화.

우리 사회에서 지난 몇년간 나왔던 말들이 ‘위험의 외주화’ 이다. 원청이 위험성이 높은 일에 대해서 외주를 주어 그와 관련된 법망과 사회적, 도덕적 책임을 회피하는 수단으로서 계약을 하는 형태… 그래서 원청에 대한 처벌을 강화해야 한다는 것이 ‘중대재해보호법’ 의 요체다.

이 위험이라는 단어가 가지는 의미는 매우 다양하다. 제조업의 경우에, 특히나 뉴스에 보도되는 경우에는 대부분 제조업이 많이 나오는데 목숨일 잃는 경우이지만 IT 의 경우에는 그야말로 프로젝트의 위험요소를 말한다.

A 라는 회사가 Cloud 로 전환 작업을 위해서 MSP 에 프로젝트를 위임하게 된다. A 라는 회사는 당연히 전문적인 식견과 인력으로 전문스러운 뭔가를 기대할 게 당연한 것이다. 하지만 MSP 회사에서는 사람을 또 뽑는다.

니들의 PL 을 알아?

Project Leader. 많은 프로젝트를 경험하면서 느낀 거지만 PL 은 아무나 해서는 안된다. PM 의 경우에는 꼭 반드시 어떤 기술적인 능력을 기대하지는 않는다. 그냥 대충 IT 에 몸을 담았던 사람정도면 그만이다. 일종의 말이 통하는 사람 정도이면 그만이다. PM 의 경우에는 프로젝트 자체의 비지니스에 대한 처리를 많이 하기 때문에 실제로 구현되어지는 프로젝트의 기술적인 부분까지 신경쓰기는 사실상 힘들다. 고객과의 협상도 PM 이 하는 일이기 때문에 PM 이 사실상 피곤한 직위에 속한다.

하지만 PL 은 이야기가 달리진다. PL 은 프로젝트에 대한 기술적인 이해가 반드시 있어야 한다. 문제는 이 프로젝트에 대한 기술적인 이해라는 것이 반드시 ‘기술’ 만 이해한다고 되는게 아니다. 이 기술들이 전체적인 요구사항에 잘 조합되어지고 있는지에 대한 사항들을 주로 살펴야 하는게 PL 이다. 예를들어, 숲에 나무를 가지고 하트모양을 만든다고 할 경우에, 나무에 대해서 알 필요는 없지만 그렇다고 몰라서도 안되고 그 나무들이 하트모양이 되도록 잘 정리 정돈이 되고 있는지 조성하는 과정에서 잘 살펴야 한다.

기술적인 내용을 세세하게 알 필요는 없지만 큰 틀에서 숲을 볼 줄 알아야, 그 숲이라는게 숲을 구성하는 각 요소들이 있기 때문에 그걸 알고 있어야 한다, 프로젝트가 잘 굴러가게 되어 있다.

PM 도 프로젝트의 승부를 가르는 결정적인 인물이라면, PL 도 실체적인 프로젝트의 승패를 가르는 인물이기도 하다. 그만큼 책임이 매우 크다는 것이다. 프로젝트에 책임에서 벗어날 수 없는 인물들이 PM, PL 이다.

그런데, 강남에 MSP 회사들은 PL 을 프리랜서로 뽑고 있다. 프리랜서가 PL 을 못한다는 이야기가 아니다. 앞에서 이야기했듯이 프로젝트를 책임질 인물이기 때문에 어찌보면 고객사 A 에 대한 예의가 아닌 거다. 자본주의 사회에서 거래계약이란게 뭐든 못할까 만은 적어도 프로젝트를 책임질 회사가 직접 나서는게 아니라 PL 을 프리랜서에게 위임한다는게 과연 정당하다고 볼 수 있나…

마치 제조업에서 위험의 외주화 정도는 아닐지라도 도의적이나 도덕적으로 별로 바른 경우는 아니다.

내 손에 피는 안 묶힌다.

왜 PL 을 프리랜서들에게 맡길려고 하는 걸까? 그들이 보기에, 한눈에 봐도 프리랜서에게 PL 을 맡기는 건 문제가 있다는 인식은 다 깔려 있다. 그런데도 이렇게 하는 이유는 다음과 같다.

‘고상한 척’ 가면놀이

강남의 MSP 회사의 경우 외주 프리랜서들을 직접 뽑지 않는다. 2차 업체라고해서 그들이 프리랜서를 물고 온다. 대부분 잡코리아, 사람인에 공고를 내서 지원하는 사람들을 대리고 오는데, 면접을 MSP 에서 보게 된다.

MSP 에 협력 업체도 인맥이지만, MSP 에서 수주하는 많은 프로젝트들 또한 인맥인 경우도 많다. 그렇지 않은 경우도 있지만 워낙 강남의 이름있는 MSP 하면 몇개 없기 때문에 업계에서도 알아서 찾아오는 경우도 있지만 그런 경우는 많지 않다.

대부분 A 업체 프로젝트 담당자와 MSP 담당자들은 대부분 인맥이 있거나 한 경우이다 보니, 서로 얼굴을 붉히는 일은 피할려고 하는 경향이 있다. 회사 생활을 하다보면 직위가 높을수록 어떤 문제에 직접 나서는걸 회피하는 경향을 보이는데, 복잡하고 스트레스가 심한 어떤 문제에 그 사람이 노출될 경우에 들어나는 인성과 능력을 무서워하는 경우가 아주 많다. 직위가 높으면 고상해지는 인간들이 대부분인 이유라고 보면 된다.

이 MSP 회사들도 마찬가지다. 프로젝트에 직접 관여하는 경우에 그런 ‘고상한 인품’ 을 유지하기가 상당히 힘든 경우다. 프로젝트를 직접 관리할 경우에 어떻게든 A 회사에게 싫은 소리도 해야하는 경우가 있고 직접 거의 매일매일 그 사람들과 이야기를 해야하는데 A 회사 사람들이 마냥 MSP 회사에 듣기좋은 소리만 할 경우는 많지 않다.

더군다나 A 회사와 인맥이라도 있는 날에는…. 힘든 일이 한두가지 아니게 된다.

‘우리는 고객사 편’

PL 를 하다보면 고객의 요구사항을 변경해야 하는 경우가 생긴다. 잘 모르니까 고객들은 어디서 주워들은 이야기를 가지고 해달라고 하는 경우도 부지기수다. 이럴 경우에 프리랜서라면 한계가 있기 때문에 수행사 MSP 회사에서 적극적으로 중재를 해야한다.

하지만 MSP 회사가 적극적으로 중재를 할려고 할까? 대부분 ‘PL 프리랜서’ 를 교체하는 방향으로 가닥을 잡는다. 심각한 건 프리랜서를 ‘능력없는 인간’, ‘성격이 안된 인간’ 쯤으로 평가하면서 교체를 한다는 문제다.

면접한번 보고 현장에 투입시키고는 그 사람들 다신 얼굴 볼 일도 생기지 않는데, 어떻게 해서 프리랜서에 저런 낙인을 찍을 권리가 생기는지?

문제가 있다는 것을 알면서도 그것을 프리랜서에 문제로 귀속시키고 교체, 그렇게 함으로써 고객의 요구사항을 변경시키는 일들을 하는 곳이 MSP 다. 그들에게는 그렇게 하는 것이 훨씬 편하니까… 프리랜서가 고객의 잘못된 요구사항에 대해서 중재를 요구하면 그건 능력이 없는 것이거나 ‘사업이란게 원래 그런건 줄 몰랐냐?’, ‘세상 덜 살았네… PL 할 인물이 못되네’ 식의 결론을 내리게 훨씬 쉽다.

이렇게 쉽게 생각하는 건 그렇게 해는 것이 너무나도 쉽고, 두번째는 프리랜서에 대한 인식이 그렇기 때문이다. 프리랜서는 본인들이 돈주고 산 사람이라는 인식이 있기 때문에 뭐든 시키면 다해야 한다는 사고를 하게 된다. 하지만 그렇지가 않지…

프리랜서의 권리는 의외로 막강하다. 하지만 그것을 주장할 경우에 계약해지를 종용하는데, 사실 다 위법한 것이지… 정당한 사유 없이 계약해지를 할 경우에 배상의무가 있다. 하지만 그런 인식이 없는 곳이 강남의 MSP 다.

사회변화는 고상하고 IT 도 제대로 안 굴러간다.

뉴스를 보면 사내에 성폭행 사건을 다루는 뉴스가 나온다. 그럴때마다 너도나도 가해자를 비난하면서 정의로운 글들을 많이 본다. 더군다나 회사측의 대응에 대해서 맹비난을 하곤 한다. 피해자편에 서서 대응을 했어야 했는데 그렇지 않고 피해자에게 ‘조용히 있어라’ 식의 대응을 했기 때문이겠지.

하지만 대부분의 한국사회가 대부분 부당함에 대해서 뭉쓰고, 모르쇠로 일관하는 일이 비일비재하다는 것쯤은 알아야 한다. 뉴스에 나오면 분노하면서도 정작 자신에게 혹은 자신과 관계된 주변에서 그런일이 발생할 경우에, 성폭력 피해자의 회사처럼 행동게 한국 사회 아니겠나..

강남의 MSP 회사들이 요즘 벌이는 일들이 이와 유사하다. 위험의 외주화는 물론이거니와 고객에게는 적어도 고상한 이미지를 구축해야하고 그러다보니 고객과의 마찰에 있어서 적극적인 중재를 하려고하지 않는다.

본인들은 고상해야 하고 적어도 피는 뭍히지 말아야 한다는 얄팥한 사고로 사람들을 뽑아대고 있으니…

제대로 된 인간들이 없다. 그져 인맥…… 그러니까 프로젝트 투입되서 보면 MSP 가 요구하는 그 엄청난 스펙에 비해 초보급 만도 못한애 구축된 아키텍쳐를 보게된다. 더 웃긴건 본인들이 구축했으니 잘 구축했다고까지 자랑질… 제 정신들이 아닌거지..

VIM lightline 플러그인

vim 을 사용할때에 필요한 것이 상태바(Status Bar) 다. 보통은 airline 을 많이 쓰는데, 여러가지 의존성이 필요해서 사용하기에 쉽지가 않다.

lightline 은 의존성이 복잡하지 않고 간단하게 사용할 수 있다. 다음과 같이 .vimrc 에 설정을해주면 된다.

t_Co=256 설정과 아래 두가지 부분의 설정이 핵심으로 보면 된다.

Elasticsearch 보안 – 인증서

Elasticsearch 가 버전이 높아짐에 따라 인증서에 대한 이해가 필요하게 되었다. 사실 이 인증서가 필요한 이유가 Elastic 에서 배포하는 X-Pack 중에 Security 플러그인 때문인데, 이 Security 를 활성화 하게 되면 TCP, HTTP 통신을 TLS 통신을 하도록 강제하고 있다.

문제는 Elasticsearch 자바 기반이며, 따라서 생성하는 파일이 여느 다른 인증서와는 다른 면도 있다. ‘다른 면도 있다’ 라고 표현한 이유는 일반적인 PEM 형식의 보안키와 인증서를 모두 지원하지만 여전히 자바 세계에서만 통용되는 방법을 여전히 고수하고 있기 때문이다.

keystore 파일

최신 버전의 Elasticsearch 7 을 설치하게 되면 /etc/elasticsearch/elasticsearch.keystore 파일 하나만 생성되게 된다.

이 파일은 key/value 형식으로 계정 정보가 들어가 있다. 이 내용을 적는 이유는 Java Keystore 파일과는 다르다는 것을 말하기 위함이다. Elasticsearch 을 설치하고 나서 Security 를 활성한 후에 계정에 대한 패스워드를 작성하는 절차를 밟는다.

계정에 대한 패스워드를 자동 생성하도록 한 것인데, 이렇게 생성된 내용들은 elasticsearch.keystore 파일에 key/value 형식으로 저장된다.

이렇게 저장된 key 값들은 elasticsearch-keystore 명령어를 통해서 볼 수 있다.

PKCS#12(확장자 p12) 파일

확장자가 p12 파일을 보게 된다. 이 파일은 PKCS#12 형식의 파일인데, 인증서와 개인키를 포함한 형태의 데이터 파일이다. Elasticsearch 7 에서는 루트 인증서(CA 인증서) 와 서버 인증서를 다음과 같이 제작해 사용 한다.

elastic-stack-ca.p12 은 CA 인증서 인데, openssl 을 이용해서 PKCS12 파일을 읽어볼 수 있다.

패스워드를 입력하지 않았기 때문에 패스워드 입력 문구에서는 그냥 Enter 를 치면 된다. 그러면 위와같이 Private Key, Certificate 내용이 나온다. Certificate 부분을 따로 때어내서 파일로 저장하고 Openssl 명령어를 이용해 인증서를 읽으면 다음과 같다.

CA:TRUE 라고 명백하게 나오고 있다.

그러면 CA 인증서를 가지고 만들어진 /usr/share/elasticsearch/elastic-certificates.p12 파일도 내용을 확인해 보자.

위 내용을 보면, Private Key 1개, Certificate 2개 로 나온다. 이건 인증서 체인 파일인게 분명하다. Certificate 부분만 따로 때어서 보면 다음과 같다.

확인 결과, 하나는 인증서이고 하나는 CA 인증서인 것으로 확인된다. 그러니까 elastic-certificate.p12 파일은 Private Key, CA 인증서, 서버 인증서 이렇게 3가지를 모두 가지는 파일이다.

PEM 형식 파일

Elasticsearch 에서는 PEM 형식의 파일도 함께 지원 한다. PEM 형식은 가장 흔하게, 널리 사용되는 인증서 파일 포맷 형식이다. elasticsearch-certutil 명령어를 이용해서 작성할 수 있다.

위와같이 zip 파일 형태로 생성된다. 압축을 해제하면 다음과 같이 파일이 생성된다.

ca 디렉토리가 생성되는데, 보면 Private Key 파일과 CA 파일이 별도로 생성된 것을 알 수 있다.

이렇게 작성된 파일을 가지고 서버 인증서를 다음과 같이 생성할 수 있다.

역시나 압축된 형태의 파일로 출력이 된다. 압축을 해제해 보자.

instance.crt 인증서 파일의 내용을 살펴보자

서버 인증서임을 알수 있다.

인증서 활용

PKCS#12 형식과 PEM 형식의 인증서를 활용하는 방법은 다르다.

PKCS#12 형식은 다음과 같이 설정 한다.

PEM 형식은 다음과 같다.

SAN 인증서

지금까지 설명한 방법으로 인증서를 작성할 경우에 한가지 문제가 있을 수 있다. 이 인증서들은 SAN 인증서가 아니기 때문에 모든 도메인에서 통용될 수 있다. 앞에 인증서 내용을 보면 SAN 이 없다. 하지만 SAN 인증서라야만 하는 보안성을 요구된다면 SAN 인증서를 만들어 사용해야 한다.

SAN 인증서를 작성할때에 주의 사항은 Elasticsearch Stack 에서 사용할 모든 도메인, 혹은 IP 주소를 기재해야 한다. 그렇지 않으면 절대로 통신을 할 수가 없게 된다.

먼저, CA 인증서가 필요하다. 이 CA 인증서는 앞에 PEM 형식의 CA 인증서를 만들고 압축을 해제해 놓는다. 그리고 다음과 같이 instance.yml 파일을 작성한다.

이 파일에서 ip, dns 항목이 보이는데, 둘 중 하나만 있어도 된다. 어짜피 인증서에서 SAN 항목에서 IP Address, DNS 둘중하나가 들어가 있고 매칭이되면 인증서를 쓸 수 있다.

이제 다음과 같이 인증서를 작성해 생성한다.

정상적으로 생성이 되었을 것이다. 압축을 해제해 보자

instance.yml 파일에서 이름부분이 디렉토리로 생성되면서 각각 인증서와 key 값이 생성되어 있다. 이 인증서들은 SAN 부분이 instance.yml 에 따라서 하나의 IP, 하나의 DNS 만 들어가 있다.

SAN 이 뭔지를 안다면 굳이 이렇게 다 분리할 필요는 없다는 생각을 하게 된다. 멀티도메인 인증서를 사용하면 도메인에 *.systemv.local 처럼 생성하면 될 것이고, 그러면 하나의 인증서를 가지고 여러곳에서 함께 사용이 가능해 진다. 위 예제에서는 각각의 용도에 맞게 딱 1개의 도메인과 IP 에 한해서 허용하도록 작성되었을 뿐이다.

PEM 형식의 Key 는 PKCS#12 형식으로 사용해야할 때가 있다. 이때는 다음과 같이 openssl 명령어를 이용해서 변환할 수 있다.

Nginx 로그를 위한 Logstash Pipeline 설정하기

Logstash 를 이용해 로그를 프로세싱 해보자. Logstash 에 대한 기초적인 설정은 다음글에서 확인 가능하다.

또, 이 글은 Elastic 홈페이지에 내용을 기반으로 한다.

filebeat 설정 및 기동

먼저 파일 filebeat 설정을 다음과 한다.

Elastic 홈페이지에는 간단하게 설정하도록 나오지만 여기서는 몇가지 설정을 추가 하였다. tags 를 설정하였고 fields 도 추가 하였다. 다음과 같이 시작 한다.

logstash Nginx pipeline 설정

먼저 filebeat 으로부터 메시지가 잘 들어오는지 디버깅을 먼저 해보자. 다음과 같이 간단하게 설정을 해본다.

INPUT 에는 filebeat 으로부터 전송을 받기 위한 port 를 지정해준다. OUTPUT 에는 디버깅을 위한 화면출력을 설정해 준다.

테스트

filebeat 의 로그 파일에 한 줄 넣어준다.

이렇게 하고 난 후에 logstash 의 출력 로그를 보면 다음과 같이 나온다.

여기서 보아야 할 것은 filebeat 에서 설정한 tags 와 field 다. 이것이 logstash 로 전송될때에 그대로 전송이 된다. message 에는 log 파일에 내용을 담고 있는데 이것을, 이제 필드별로 구별을 해야 한다. 이를 위해서는 로그의 형식을 알아야 한다.

Nginx 로그 형식

Nginx 의 로그 형식은 nginx 설정 파일에 log_format 에 기록되어 있다.

이 형식은 필요에 따라서 변경 될 수 있다. 이 형식을 알아야 한다.

Logstash FILTER pipeline 설정

이제 Nginx Pipeline 에 FILTER 를 설정해야 한다. 일 FILTER 는 들어오는 메시지를 가공처리해주는데, grok 을 이용한다. 메시지를 가공처리하는데 미리 정의된 형식도 지원한다. 다음과 같이 해보자.

filebeat 는 한번 읽은 로그는 다시 읽지 않는다. filebeat 는 중지 시키고, 데이터 디렉토리에 registry 디렉토리를 삭제 한다.

이렇게 하면 파일을 다시 읽는다. 하지만 결과는 필드로 구분되지 않았다. 이것은 미리 정의된 FILTER 가 적용되지 않았음을 의미 한다.

FILTER 의 적용은 grok 을 사용하는데, 이것을 매번 해보는건 힘들다. 그래서 온라인으로 테스트를 할 수 있도록 도와주는 사이트가 있다.

여기에서 샘플데이터를 넣은 후에 패턴을 grok 패턴으로 적용하면 결과를 보여준다. 이 패턴을 이용하면 된다.

grok 의 사용법은 %{SYNTAX:SEMANTIC} 형식인데, SYNTAX 는 패턴이다. SEMANTIC 는 그 패턴을 담는 변수라고 보면 된다. 그런데, 이 패턴은 미리 정의되어 있는데, 다음에서 확인 가능하다.

Nginx 형식에 맞는 grok 패턴을 다음과 같이 입력 해줬다.

이렇게 한 후에 로그를 전송하면 다음과 같이 잘 파싱된다.

Elasticsearch 보안

Elasticsearch 가 버전이 높아지면서 보안이 강화 됐다. 더군다나 Security 플러그인을 활성화할 경우에 각종 Rules와 Roles 들이 생성된다. 뭔가를 하기 위해서는 인증을 거쳐야 한다는 뜻이다.

Logstash 는 최종적으로 Elasticsearch 로 데이터를 보내야 한다. 이에 대한 보안 설정이 필요한데, 이에 대한 자세한 설명은 다음에 잘 나와 있다.

CA 인증서 설정

Elasticsearch 8.1 을 설치할때에 CA 인증서가 config/certs 디렉토리에 생성 되었다. RPM 으로 설치하였을 경우에 /etc/elasticsearch/certs 디렉토리인데, 여기에 http_ca.crt 파일로 존재 한다. 이것을 Logstash 에 OUTPUT 필터에서 사용해야 한다.

Logstash 를 위한 자격증명 만들기

자격증명을 만들기 위해서는 권한을 부여한 역할(Role) 를 만들어야 한다. Kibana 를 설치했다면 Management > Roles 에서 생성할 수 있다. 다음과 같이 만든다.

  • Role 이름: logstash_writer
  • Cluster Privileges: manage_index_templates, monitor, manage_ilm
  • Indices Name: nginx-access-*
  • Indices Privileges: write, create, create_index, manage, manage_ilm
Logstash 를 위한 Role 생성

이것은 다음과 같이 curl 을 이용할 수도 있다. 먼저 Role 을 위한 JSON 파일을 작성한다.

그리고 이제 다음과 같이 curl 명령어를 작성해 실행하면 된다.

이제 사용자를 만들어야 한다. 사용자를 만들때에는 패스워드도 함께 생성하고 앞에서 만든 logstash_writer 롤을 할당해 준다.

Logstash 를 위한 계정생성

역시 이것도 다음과 같이 JSON 형식으로 생성이 가능하다.

logstash OUTPUT 파이프라인 설정

이제 Logstash 의 OUTPUT 파이프라인을 설정해야 한다. 다음과 같다.

결론

logstash OUTPUT 파이프라인 설정이 되면 logstash 와 filebeat 을 재시작 하고 nginx 로그를 넣게 되면 이제 Elasticsearch 에 nginx-access-날짜 로 인덱스가 생성되면서 데이터가 적재된다.

Logstash 살펴보기

ELK 스택에서 로그를 프로세싱하고 저장소에 실시간으로 적재해주는 프로그램인 Logstash 에 대해서 살펴본다.

자바 프로그램

Logstash 는 자바 프로그램이다. 그래서 Java Runtime 이 필요하다. 그런데, Logstash 에는 Java Runtime 이 내장되어 있어서 별도로 설치하지 않아도 된다.

하지만 이 자바 때문에 프로그램이 무겁다.

Logstash 정의

다음과 같이 정의가 머리속에 담아 두기 좋다.

실시간 파이프라인(Pipeline) 기능을 가진 데이터 수집 엔진을 가진 오픈 소스 소프트웨어다.

파이프라인(Pipeline)

Logstash 는 파이프라인(Pipeline) 형식으로 데이터를 처리 한다.

INPUTS 은 데이터를 입력받는 부분에 대한 설정이다. OUTPUTS 은 어디로 데이터를 보낼 것인지 하는 부분인데, 대부분 데이터 저장소를 지정한다. FILTERS 부분은 입력받은 데이터를 가공처리하는 부분을 말하는데, Logstash 의 핵심부분이라고 할 수 있다.

logstash 플러그인

logstash 는 자체 플러그인을 가지고 있다. 이 플러그인을 활용하면 미리 설정된 FILTERS 에 맞게 로그를 처리하고 OUTPUT 을 해준다.

logstash 를 설치했다면 다음과 같이 지원되는 리스트를 확인해 볼 수 있다.

OUTPUT 플러그인 중에 Elasticsearch 를 설치해 보자.

logstash.yml

이 파일은 Logstash 실행을 제어하기 위한 것이다. 파이프라인 세팅, 설정 파일 위치 지정, 로깅 옵션등을 지정할 수 있다. 이 파일에 적은 옵션은 커맨드 라인으로 지정해도 된다.

주요한 설정은 다음과 같다.

logstash.yml 파일에 pipeline 관련 설정도 있다. 이것 때문에 헷깔리는 사람들이 많은데, 여기서 pipeline 설정을 하지 않아도 된다. 각각의 pipeline 설정은 pipeline.yml 에서 설정하는데, 여기서 설정하지 않은 값은 logstash.yml 파일에서 읽어 들인다. 쉽게 말해서 Default 값을 지정하는 것이라고 보면 된다.

pipeline.yml

pipeline 에 대한 설정을 하는 것이다. 대략 다음과 같다.

path.config 에서 디렉토리에 .conf 확장자 파일을 모두 읽어 들이도록 한다.

-f 옵션 없이 실행

보통 -f 옵션을 주고 실행하는 이유는 pipeline 설정파일을 지정하기 위해서다. 하지만 logstash.yml 과 pipeline.yml 파일을 작성했다면 -f 옵션 없이 실행할 수 있다.

위에 두가지 설정을 한 이유다.

로그 저장과 트래킹

로그(log) 는 각종 시스템과 소프트웨어 프로그램의 정보를 담고 있다. 한 사람이 하나의 시스템, 하나의 소프트웨어 프로그램을 다루거나 관리를 한다면 별 문제가 없겠지만 요즘 처럼 분산형 시스템과 소프트웨어를 사용하는 시대에 로그를 하나씩 다 들여다 본다는 건 불가능이다.

거기다 로그를 본다는 것도 여간 쉬운일이 아니다. 매우 지루하고 많은 시간을 허비해야 하는데, 수 많은 로그속에서 내가 필요로하는 정보를 찾기란 매우 어렵다.

그래서 이것을 손쉽게 처리할 수 있도록 도와주는 프로그램 그룹이 만들어졌는데, 다음과 같은 것이다.

Splunk

스플렁크(Splunk) 는 사용 소프트웨어다. 대량으로 로그를 저장하고 분석하도록 해주는 소프트웨어를 판매하는 회사다. 상용제품이다 보니까 이 제품을 익히는게 중요하다. Splunk Search Processing Language, 줄여서 SPL 을 이용해서 로그에서 필요한 정보를 뽑아 낼 수 있다.

ELK(Elasticsearch, Logstash, Kibana)

Elastic 제품군이다. 엘라스틱서치(Elasticsearch) 검색 소프트웨어로 유명한 Elastic 에서 만드는 것인데, 로그스태쉬(Logstash) 는 실시간으로 로그를 전달 받아서 처리하고 이것을 엘라스틱서치에 저장한다. 키바나(Kibana) 는 엘라스틱서치에 저장한 로그들을 특저한 쿼리를 이용해 시각화 해준다.

로그스태쉬(Logstasch) 대신 플로언트디(FluentD) 를 사용하기도 한다. 로그스태쉬로그스태쉬(Logstasch)보다 메모리를 덜 먹으면서도 가용성이 좋다.

로그 처리를 위한 ELK 를 스택(Stack) 이라고 명명하고 ELK Stack, EFK Stack 이라고 부른다.

ELK stack components

TICK(Telegraf, InfluxDB, Chronograf, Kapacitor)

InfluxDB 와 Telegraf 로 유명한 InfluxData 에서 만든 것이다. Kapacitor 는 ELK 에서 로그스태쉬에 해당한다. Chronograf 는 ELK 의 키바나에 해당된다.

개인적으로 Telegraf, InfluxDB, Grafana 를 이용한 시스템 모니터링은 여러번 사용해본 경험이 있다. InfluxDB 는 마치 RDBMS 처럼 SQL 문을 이용해서 데이터를 조회할 수 있다.

ElasticSearch RPM 패키지 설치 Security

ElasticSearch 를 RPM 패키지로 설치할 경우에 Security 설정을 어떻게 해야하는지에 대해서 다룬다. Security 설정은 X-Pack 을 활성화 하기 위함이며 이를 위해서는 인증서 관련 문제를 해결해야 한다.

사례

일단, 엘라스틱 서치는 대부분 3대로 구성한다. 대부분 호스트를 다음과 같이 정할 것이다.

  • es-01
  • es-02
  • es-03

이때, es-01 서버에서 다음과 같은 작업을 해야 한다.

es-01 서버에서 인증서 작업

X-Pack 을 활성화하기 위해서는 보안을 활성화해야 하는데, 보안을 활성화할 경우에 각 노드별로 SSL 통신을 하게된다. 이때 인증서가 필요한데, 인증서 작업을 해야 한다.

중요한 것은 인증서를 한 곳에서 해야하고 모두 서버에 배포를 해야 한다. 여기서는 es-01 서버에서 하는 것으로 가정한다.

뭐라 뭐라 나오지만 중요한건 위 두줄인데, 그냥 Enter 만 두번 쳐주면 된다. 이렇게 하면 /usr/share/elasticsearch 디렉토리에 ‘elastic-stack-ca.p12’ 파일이 생성된다.

그리고 이제 루트 인증서를 가지고 인증서를 다음과 같이 만든다.

역시 뭐라뭐라 나오는데, Enter 만 세번 쳐준다. 이렇게하면 /usr/share/elasticsearch 디렉토리에 ‘elastic-certificates.p12’ 파일이 생성된다.

위 과정으로 인해서 2개의 파일 ‘elastic-stack-ca.p12’, ‘elastic-certificates.p12’ 파일이 생성된다.

이 두개의 파일을 이제 3개의 엘라스틱서버 모두에 /etc/elasticsearch 디렉토리로 복사해 준다. 그리고 다음과 같이 소유권과 퍼미션을 변경해 준다.

설정

이제 3대 서버 모두에 ‘elastic-stack-ca.p12’, ‘elastic-certificates.p12’ 두개 파일이 /etc/elasticsearch 디렉토리에 있을 것이다. 모두 es-01 에서 만든 같은 파일이다.

이제 각 서버의 /etc/elasticsearch/elasticsearch.yml 파일 맨 마지막에 다음과 같이 설정을 해준다.

이게 es-01 서버부터 시작을 해준다. 그러면 잘 될 것이다.

패스워드 생성

마지막으로 엘라스틱서치에 인증이 필요한 계정에 패스워드를 생성해 준다.

Kibana 에서는 username 이 kibana 계정과 위에서 생성한 패스워드를 입력해 준다.

Kubernetes API 서버 인증서에 도메인 추가하기

Kubernetes API 서버는 http 를 통해서 쿠버네티스에 대한 연산을 제공해 준다. kubectl 명령어로 실행되는 것들은 모두 API 서버를 거쳐서 이루어진다. 하지만 API 서버는 인증서를 기반으로 통신이 이루어지는데, 이 인증서에 기재된 도메인이나 IP가 아니면 통신이 이루어지지 않는다.

API 서버의 인증서는 SAN 인증서여야 한다. 도메인 리스트를 가지고 있는 SAN 인증서. 현재 API 서버의 인증서 상태는 다음과 같다.

위 apiserver.crt 파일 상태를 보면 SAN 에 이미 도메인과 IP 들이 들어가 있다. 내용을 보면 haproxy2.systemv.local 도메인, 192.168.96.7 IP 가 들어가 있는데 이 서버에서 API 서버와 통신이 가능하다.

만일 추가적으로 도메인, IP 를 추가하고 싶다면 어떻게 해야할까? 이에 대해서 알아본다.

kubeadm-config 업데이트

kubeadm-config 라고 불리는 ConfigMap 을 업데이트 해줘야 한다. 이를 위해서 먼저 기존이 설정을 뽑아내야 하는데 다음과 같이 하면 된다.

파일 내용을 보면 SAN 리스트가 없다. 도메인이나 IP 를 SAN 으로 추가하기 위해서 apiServer 아래에 certSANs 를 추가해 준다. 이미 다른 도메인이 있다면 제거하나 추가할 수도 있다.

위와같이 SAN 에 추가할 도메인, IP를 적어준다.

apiserver.crt 파일 업데이트

기존의 존재하는 apiserver.crt 파일을 백업한다.

kubeadm 을 이용해 새로운 인증서를 생성해 준다.

새로운 인증서가 생성되면서 certSANs 에 설정된 도메인, IP 주소들이 모두 인증서에 업데이트 된다. 이제 새로운 인증서를 가지고 구동되도록 api 서버를 재시작 시켜줘야 한다.

Docker 기반의 경우에는 다음과 같이 하면 된다.

  • docker ps | grep kube-apiserver 명령어로 kube-apiserver 의 컨테이너 ID 를 파악한다.
  • docker kill <containerID> 로 컨테이너를 킬(kill) 한다. 이렇게 하면 api 서버가 재시작 된다.

만약 containerd 를 이용하는 경우에는 다음과 같이 하면 된다.

  • crictl pods | grep kube-apiserver 로 kube-apiserver 의 Pod ID 를 파악한다.
  • crictl stopp <pod-id> 로 pod 를 정지
  • crictl rmp <pod-id> 로 pod 를 제거 합니다. 이렇게하면 다시 Pod 가 재시작 된다.

위와같이 Api 서버가 재시작되면서 새롭게 만들어진 API 서버 인증서를 인식하게 된다.

클러스터 설정 업데이트

마지막으로 클러스터 설정을 업데이트 해줘야 한다.

이렇게 하면 최종적으로 Api 서버에 인증서가 업데이트 된다.

Kubernetes 의 Role Based Access Control(RBAC)

쿠버네티스는 RBAC 기반으로 허가권(Permission) 을 조정하도록 설계 되었다. 그런데, 쿠버네티스는 다음과 같이 네가지의 Role 관련 리소스를 가지고 있다. 그 차이는 다음과 같다.

  1. ClusterRole – 전체 클러스터에 적용하기 위한 역할(Role) 에 할당된 허가권(Permission)
  2. ClusterRoleBinding – 특정 계정(Account) 에 ClusterRole 을 바인딩
  3. Role – 특정 네임스페이스에 적용하기 위한 역할(Role) 에 할당된 허가권(Permission)
  4. RoleBinding – 특정 계정(Account) 에 Role 을 바인딩

RBAC 을 적용하기 위해서는 계정이 필요하다. 이 계정은 쿠버네티스의 사용자를 말하는것이 아닌 쿠버네티스에서 운영되는 자원에 대한 계정을 말한다.

예를들어 ingress-nginx 라는 계정을 생성했다면 이제 이 계정에 ClusterRole 과 Role 을 Binding 을 통해서 ingress-nginx 계정과 연결하는 형식이다.

참고: Role Based Access Control (RBAC)