Ansible Tower의 OpenSource격인 AWX를 설치해 보자.
CentOS 7 쉘에서 아래 커맨드 입력하면 된다.

물론 모두 기본 비번이므로 운영용으로 쓰기 위해서는 awx/installer 부분을 수정해야하고,

쿠버네티스를 이용해서 클러스터를 구축을 할 필요가 있다.

아래는 단일 서버에 Docker-Compose로 구축하는 가장 빠르고 심플한 방법이다.
Docker-Compose 최신버전에는 실행이 안되므로 1.23.2 로 고정해야 한다!

#!/usr/bin/env bash

sudo yum -y install epel-release 
sudo yum -y install yum-utils ansible git python-pip gcc

sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
sudo yum -y install docker-ce
sudo systemctl enable docker
sudo systemctl start docker
sudo pip install -U pip docker-compose==1.23.2

git clone https://github.com/ansible/awx.git
cd awx/installer/
mkdir -p /var/awx
sed -i 's/\/tmp\/pgdocker/\/var\/awx\/pgdocker/g' inventory
ansible-playbook -i inventory install.yml -b

완료되면 Public IP로 접속, 실제 스크립트 실행후 3~5분정도 초기화 시간이 필요하다.

구인 공고 내용이 뭐 이렇게 멋있냐...

About the job

Hope is not a strategy. Engineering solutions to design, build, and maintain efficient large-scale systems is a true strategy, and a good one.

Site Reliability Engineering (SRE) is an engineering discipline that combines software and systems engineering to build and run large-scale, massively distributed, fault-tolerant systems. SRE ensures that Google's services—both our internally critical and our externally-visible systems—have reliability and uptime appropriate to users' needs and a fast rate of improvement while keeping an ever-watchful eye on capacity and performance.

SRE is also a mindset and a set of engineering approaches to running better production systems—we build our own creative engineering solutions to operations problems. Much of our software development focuses on optimizing existing systems, building infrastructure and eliminating work through automation. As SREs are responsible for the big picture of how our systems relate to each other, we use a breadth of tools and approaches to solve a broad spectrum of problems. Practices such as limiting time spent on operational work, blameless postmortems and proactive identification of potential outages factor into iterative improvement that is key to both product quality and interesting and dynamic day-to-day work.

SRE's culture of diversity, intellectual curiosity, problem solving and openness is key to its success. Our organization brings together people with a wide variety of backgrounds, experiences and perspectives. We encourage them to collaborate, think big and take risks in a blame-free environment. We promote self-direction to work on meaningful projects, while we also strive to create an environment that provides the support and mentorship needed to learn and grow.

To learn more: check out Site Reliability Engineering, written by Google SREs, watch a recorded Hangout on Air to meet some of our SREs, or read a career profile about why a software engineer chose to join SRE.

Behind everything our users see online is the architecture built by the Technical Infrastructure team to keep it running. From developing and maintaining our data centers to building the next generation of Google platforms, we make Google's product portfolio possible. We're proud to be our engineers' engineers and love voiding warranties by taking things apart so we can rebuild them. We're always on call to keep our networks up and running, ensuring our users have the best and fastest experience possible.

 

희망은 전략이 아닙니다. 효율적인 대규모 시스템을 설계, 구축 및 유지 관리하는 엔지니어링 솔루션은 진정한 전략이며 좋은 솔루션입니다.

SRE (Site Reliability Engineering)는 소프트웨어 및 시스템 엔지니어링을 결합하여 대규모, 대규모 분산, 내결함성 시스템을 구축 및 실행하는 엔지니어링 분야입니다. SRE는 Google의 내부적으로 중요한 시스템과 외부에서 볼 수있는 시스템 모두의 서비스가 용량과 성능에 대해 끊임없이 주시하면서 사용자의 요구와 빠른 개선 속도에 적합한 안정성과 가동 시간을 보장합니다.

SRE는 또한보다 나은 생산 시스템을 실행하기위한 사고 방식이자 일련의 엔지니어링 접근 방식입니다. 우리는 운영 문제에 대한 독창적 인 엔지니어링 솔루션을 구축합니다. 우리의 소프트웨어 개발의 대부분은 기존 시스템 최적화, 인프라 구축 및 자동화를 통한 작업 제거에 중점을 둡니다. SRE는 시스템이 서로 어떻게 관련되어 있는지에 대한 큰 그림을 담당하기 때문에 광범위한 문제를 해결하기 위해 폭 넓은 도구와 접근 방식을 사용합니다. 운영 작업에 소요되는 시간을 제한하고 비난을받지 않고 사후 조치를 취하고 정전 사태를 사전에 파악하는 등의 업무는 제품 품질과 흥미롭고 역동적 인 일상 업무의 핵심 요소 인 반복적 인 개선 요인으로 작용합니다.

다양성, 지적 호기심, 문제 해결 및 개방성에 대한 SRE의 문화는 성공의 열쇠입니다. 우리 조직은 다양한 배경, 경험 및 전망을 가진 사람들을 모아 듭니다. 우리는 그들이 비난이없는 환경에서 협력하고, 생각하고, 위험을 감수 할 것을 권장합니다. 우리는 의미있는 프로젝트를 수행하기 위해 자조를 추진하고 배우고 성장하는 데 필요한 지원과 멘토링을 제공하는 환경을 조성하기 위해 노력합니다.

자세히 알아 보려면 Google SRE가 작성한 Site Reliability Engineering,을 확인하거나, SRE의 일부를 충족 할 수 있도록 녹화 된 Hangout on Air를 보거나, 소프트웨어 엔지니어가 SRE에 가입 한 이유에 대한 career profile을 읽으십시오.

사용자가 온라인에서 볼 수있는 모든 것의이면에는 기술 인프라 스트럭처 팀이 구축 한 아키텍처가 있습니다. Google 데이터 센터 개발 및 유지 관리에서 차세대 Google 플랫폼 구축에 이르기까지 Google은 Google의 제품 포트폴리오를 가능하게합니다. 우리는 엔지니어 엔지니어가되어 자랑스럽게 생각하며, 물건을 분해하여 보증을 무효화함으로써 제품을 다시 만들 수 있습니다. 우리는 네트워크 운영을 유지하기 위해 항상 최선을 다하고 있습니다.

최근에 nGrinder를 통해 부하테스트를 할일이 급하게 생겼다.

jMeter는 다운받으면 바로 실행가능하지만, nGrinder는 컨트롤 서버와 에이전트가 구분되어 있다.
Docker가 지원되어서 한결 쉽게 설치 가능합다.

  1. 일단 CentOS 7기반의 VM 3개를 띄운다.(서버용 1대, 에이전트용 2대 (원하는 만큼))

  2. 아래 커맨드로 각 서버에 모두 docker를 설치한다.

    sudo yum install -y yum-utils device-mapper-persistent-data lvm2
    sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
    sudo yum install -y docker-ce docker-ce-cli containerd.io
    sudo systemctl enable docker
    sudo systemctl start docker
  3. 컨트롤 서버용 nGrinder 컨테이너 1대 먼저 설치

    docker pull ngrinder/controller:3.4
    docker run -d -v ~/ngrinder-controller:/opt/ngrinder-controller -p 80:80 -p 16001:16001 -p 12000-12009:12000-12009 ngrinder/controller:3.4
  4. 에이전트용 2대에 각각 설치 ( CONTROL_SERVER_IP는 3번의 VM IP 사용 )

    docker pull ngrinder/agent:3.4
    docker run -v ~/ngrinder-agent:/opt/ngrinder-agent -d ngrinder/agent:3.4 CONTROL_SERVER_IP:80
  5. 웹으로 CONTROL_SERVER_IP로 접속하면 끝

 

편향적인 내용으로 당연히 절대 평가는 되지 않습니다. 상황에 맞게 써야 하며, 특성을 참고하는데 도움은 됩니다.

원문: https://bitworking.org/news/2017/03/prometheus

우리는 모든 모니터링을 InfluxDB 에서 Prometheus로 마이그레이션하는 작업을 끝내 었습니다. 변화에 대한 이유를 적어 두었 습니다. 이 내용은 저의 개인적인 관찰이며 특정 프로젝트와 관련이 있습니다. 이러한 문제는 귀하에게 적용되지 않을 수 있으며 각 제품을 귀하 자신의 용도로 평가해야합니다.

업데이트 : 명확히하기 위해 InfluxDB와 Prometheus의 버전은 InfluxDB 1.1.1과 Prometheus 1.5.2입니다.

Push vs Pull

InfluxDBInfluxDB는 Push 기반 시스템입니다. 즉, 실행중인 응용 프로그램이 데이터를 모니터링 시스템에 적극적으로 Push해야합니다. Prometheus는 Pull 기반 시스템이며, Prometheus 서버는 주기적으로 실행중인 응용 프로그램에서 메트릭 값을 가져옵니다.

Prometheus로 폴링하는 방법을 중앙에서 제어 할 수 있기 때문에 Prometheus 서버의 구성을 조정하는 것만으로 매분마다 폴링을 전환 할 수 있습니다. InfluxDB를 사용하면 메트릭을 얼마나 자주 Push해야하는지에 대한 변경으로 모든 애플리케이션을 재배포해야합니다. 또한 Prometheus pull 메서드를 사용하면 Prometheus가 응용 프로그램의 실행 여부를 모니터링하는 합성 "UP"메트릭을 만들고 제공 할 수 있습니다. 수명이 짧은 애플리케이션의 경우 Prometheus에는 푸시 게이트웨이가 있습니다.

데이터 저장소

InfluxDB는 메트릭 값과 인덱스 모두에 대해 모 놀리 식 데이터베이스를 사용합니다. Prometheus는 지표에 대해 LevelDB를 사용하지만 각 측정 항목은 자체 파일에 저장됩니다.

둘 다 키 / 값 데이터 저장소를 사용하지만 키 스토어를 사용하는 방법은 매우 다르며 제품의 성능에 영향을 미칩니다. InfluxDB는 느린 속도 였고 똑같은 측정법으로 Prometheus보다 훨씬 많은 디스크 공간을 차지했습니다. InfluxDB를 시작하고 그로 인해 측정 된 데이터의 수가 적 으면 데이터 저장소가 1GB로 증가한 다음 Prometheus가 모든 측정 항목을 사용하여 아직 10GB를 크랙하지 않은 채로 전체 측정 항목에 대해 데이터 저장소를 100GB까지 빠르게 확장했습니다. . InfluxDB가 우리가 실행하고 있던 InfluxDB 버전을 업그레이드하려는 시도가 실패하거나 실패했을 때 InfluxDB가 모든 데이터를 잃어 버렸습니다.

업데이트 : Prometheus는 몇 초 만에 시작되는 반면, InfluxDB는 색인을 유효화하거나 다시 작성하는 동안 정기적으로 5 분이 걸리고 전체 프로세스 중에 데이터를 수집하지 않는 등 시작 시간에 관한 또 다른 데이터 저장소 관련 문제가 있음을 상기했습니다.

CPU

아마도 데이터 저장소의 효율성과 밀접한 관련이있는 InfluxDB는 실행중인 서버를 최대한으로 늘려 가고 있었지만 Prometheus는 동일한 인스턴스에서 최대 0.2 개의로드를 넘었습니다.

검색어 언어

InfluxDB는 SQL의 변형을 사용합니다. Prometheus는 실질적으로 보다 간단하고 직접적인 쿼리 모델을 사용합니다.

무엇을 입력 하시겠습니까?

SELECT * FROM "cpu_load_short" WHERE "value" > 0.9

또는

cpu_load_short > 0.9

설정

InfluxDB : 설정 파일 & SQL 명령의 혼합

Prometheus : 텍스트 파일 사용

Prometheus 설정은 간단히 YAML 파일이며, 전체 설정은 파일을 통해 이루어진다. InfluxDB를 사용하면 예를 들어 메트릭스를 저장할 명명된 데이터베이스를 생성하는 등의 구성 중 일부가 실제로 수행되는 것을 우려해야 한다. 또한 Prometheus는 15일 동안만 데이터를 저장하는 것이 기본이고, InfluxDB는 모든 데이터를 영구적으로 저장하는 것이 기본이며, 모든 데이터를 영구적으로 저장하지 않으려면 데이터가 보존되는 방법을 제어하기 위해 서버로 전송하는 SQL 명령을 생성해야 한다.


  • clone 받은 상태로 원복 할려면 해당 경로로 이동 후

git checkout . && git clean -fdx


  • git add 이전

git checkout DIR_PATH    #특정 폴더 아래의 모든 수정 사항 원복

git checkout .      # 현재 폴더 아래 모든 수정 사항 원복

git checkout FILE_PATH     #특정 파일 원복


  • git add 한 경우

git reset


  • git commit 까지 한경우 : 
    • commit 내용을 없애고 이전 상태로 원복

master 브랜치의 마지막 커밋을 가리키던 HEAD를 그 이전으로 이동시켜서 commit 내용을 없앰

git reset --hard HEAD^

    • commit은 취소하고 commit 했던 내용은 남기고 unstaged 상태로 만들기

git reset HEAD^

    • commit은 취소하고 commit 했던 내용은 남기고 staged 상태로 만들기

git reset --soft HEAD^


  • 불필요한 파일 및 디렉토리 지우기 (untracked)

git clean -fdx


  • git push를 한 경우 remote repository도 이전으로 되돌리기

git reset HEAD^

git commit -m "..." 

git push origin +master


마이크로서비스로만 가면 만능일것 같은 시대에 한번 쯤 읽고 고민해 볼만한 글이다.


"마이크로서비스는 답이 아니었다"··· 세그먼트가 모놀리틱으로 돌아온 이유

Tamlin Magee | Computerworld UK


원문보기: http://www.ciokorea.com/news/39258

다른 많은 기업과 마찬가지로, 데이터 스타트업 세그먼트(Segment) 역시 오래된 인프라스트럭처로 인한 문제 때문에 마이크로서비스(microservice)로 눈을 돌렸다. 하지만 곧 단일 구조(monolithic) 아키텍처로 돌아오지 않으면 해결할 수 없는 복잡한 문제가 있다는 것을 깨달았다.

세그먼트의 주 고객은 타임(Time), IBM, 리바이스(Levi’s) 등이다. 이들 기업의 모든 고객 데이터를 세일즈, 애널리틱스, 헬프데스크 등에 피딩하기 전에 한 지점에 모아 볼 수 있는 서비스를 제공한다.

세그먼트의 CTO이자 공동창립자인 캘빈 프렌치-오웬은 “처음에는 단일 API와 라이브러리를 제공하고 그들이 데이터를 보내오는 식의 개발자 우선 방식을 택했다. 우리가 데이터를 모아 구성한 후 이를 적절한 스키마로 정렬하고, 고객사가 사용하는 200여 가지 이상의 툴에 이 데이터를 보냈다. 여기서 툴이란 세일즈포스 같은 세일즈 툴 일수도 있고, 젠데스크(Zendesk) 같은 고객 관련 툴, 혹은 레드시프트(Redshift)나 빅쿼리(BigQuery)같은 데이터 웨어하우스 일수도 있다”라고 말했다.

세그먼트사는 전적으로 AWS에 의존하고 있으며, ECS(Elastic Container Service)가 관리하는 1만 6000개 컨테이너가 250여 가지 마이크로서비스를 제공한다.

세그먼트는 원래 단일 구조 아키텍처를 사용했다. API가 데이터를 처리해 싱글 큐(queue)에 포워딩하면 직원이 데이터를 읽고 이벤트를 모든 서버측 ‘목적지’, 그러니까 파트너 API에 선형 체인을 통해 전송했다. 그러나 이런 방식은 이내 문제를 발생시켰다. 툴에서 서버 에러를 반송할 때의 재시도가 큐와 만나 다른 이벤트와 뒤섞이는 것이다. 이로 인해 파이프가 막히고 성능 장애로 이어졌다.

세그먼트의 소프트웨어 엔지니어 알렉스 누난은 “단일 구조에서 탈피해 마이크로서비스로 전환한 것도 이 때문이었다. 우리에게는 데이터를 수집하는 API와 라우터가 있고, 라우터는 이벤트를 목적지별 큐와 서비스로 라우팅했다. 이벤트가 발생하면 라우터가 ‘좋아, 이 이벤트는 구글 애널리틱스와 맥스 패널로 보내야겠어’라고 판단을 내리고 해당 이벤트의 카피를 2개 생성해 각각의 큐로 이를 보내는 식이었다”라고 말했다.


바람 잘 날 없었던 “마이크로서비스”의 세계

마이크로서비스 방식은 한동안 잘 돌아 가는 것처럼 보였다. 그러나 역시 문제가 발생했다. 누난의 표현을 빌리면 '마이크로서비스 세계의 더 깊숙한 곳에서 개별 파트너의 API 목적지와 서비스에 대한 새로운 타입의 큐가 형성됨'에 따라 발생했다. 결국 개발자는 모든 업데이트를 수동으로 처리해야 했고 어떤 업데이트 버전이 어디의 어느 리포(repo)에 있는지를 일일이 기억하는 것이 한계에 다다랐다.

누난은 “시간이 갈수록 개발자의 생산성이 급격히 저하됐다. 모든 것이 각기 다른 별개의 큐와 별개의 서비스, 그리고 자체적인 리포에 있었기 때문이다. 우리는 통합을 유지, 생성하기 위해 공유 라이브러리를 만들었지만 이것을 전개할 좋은 방법도, 또 제대로 테스팅할 여건도 안됐다. 공유 라이브러리를 업데이트하기에는 시간도 자원도 부족했다. 결국 구글 애널리틱스 버전만 업데이트하는 식이 됐다. 모든 라이브러리가 서로 다른 업데이트 버전을 갖게 됐다"라고 말했다.

세그먼트 팀은 파트너 API가 각각 어느 라이브러리 버전에서 구동되는지 추적하고, 그 버전 간의 차이도 기억해야 했다. 누난은 “라이브러리 관리 업무 만으로도 개발자에게 너무 큰 부담이 됐다. 꾹 참고 서비스마다 하나하나 변경할 수도 있지만 그러려면 수 일이 걸렸고, 특히 서비스 하나 하나를 테스트하고 전개하는데 여러 명의 개발자가 필요하게 됐다. 이것이 너무 큰 부담으로 작용한 끝에 결국 꼭 필요한 변경사항조차도 적용하지 않게 되는 일까지 발생했다. 모든 서비스에 아주 작은 변경사항만 적용하기 위해서도 팀 전체가 달려 들어 일주일 이상 소모해야만 했다”라고 말했다.

세그먼트의 직원은 이러한 큐를 처리하기 위해 수면 부족에 시달리는 것도 모자라, 성능 이슈에도 직면했다. 예를 들어 구글 애널리틱스와 같은 대규모 목적지의 경우 초당 수천 건에 달하는 이벤트를 처리하는 반면 하루에 수 건 이내의 이벤트만을 처리하는 곳도 있었다. 세그먼트 팀은 오토-스케일링 룰을 적용해 이러한 서비스의 수동 커스터마이징을 최소화 했지만 서비스마다 고유의 CPU 및 메모리 로드 패턴이 있었기 때문에 모든 통합에 같은 룰을 적용할 수는 없었다.

누난은 “하루에도 수십 번씩 쉴 새 없이 호출이 왔고, 직원이 일일이 개입해 이러한 서비스를 처리해야 했다. 이런 식으로 2년 넘게 마이크로서비스 방식을 이용한 결과 큐와 리포에 140여 가지 서비스를 갖게 됐지만 시스템 장애를 막는 데에만 모든 에너지를 쏟아도 역부족이었기에 그보다 더 건설적이거나 선제적인 어떤 노력도 할 수 없는 상황이었다. 이쯤 되자 한걸음 물러나 생각해 보지 않을 수 없었다. ‘대체 이 상황을 해결하려면 어떻게 해야 하지?’ 결국 인력을 추가해야 한다는 결론이 나왔지만, 그런 식으로 문제를 해결하고 싶지는 않았다”라고 말했다.

그러나 결국 세그먼트는 마이크로서비스 아키텍처가 지속 불가능하다는 결론에 다다랐다. 목적지를 추가할수록 성능 저하가 눈에 띄게 증가했고 이것은 ‘상당히 뚜렷한 경고 신호’였다. 누난은 “한창 마이크로서비스로 인한 광기가 극에 달했을 때 내가 세그먼트에 합류했다. 당시 이미 어떻게 하면 이 문제를 해결할 것인가에 대한 논의가 이루어지고 있었다”라고 말했다.



단일 구조로 돌아가다

세그먼트 팀은 마이크로서비스를 어떻게 다시 하나의 거대한 시스템으로 재설계할 것인지 방법을 찾아야 했다. 이른바 ‘신(新) 단일구조’로의 이행이었다. 결국 당시 세그먼트가 진행 중이던 ‘센트리퓨즈(Centrifuge)’ 인프라스트럭처 프로젝트를 통해 새로운 단일 구조로 이행하기로 결정됐다. 센트리퓨즈는 세그먼트 비즈니스의 핵심이라 할 수 있는 단일 이벤트 딜리버리 시스템이다.

프렌치-오웬은 “센트리퓨즈는 큐를 생성하고 실패가 발생했을 때 트래픽을 흡수하기 위한 시스템이다. 이 시스템 덕분에 우리는 여러 코드를 한 장소에 통합하고, 이를 통해 두 마리 토끼를 잡는 전략을 취하기로 했다"라고 말했다.

이를 위해 먼저 모든 목적지 코드를 하나의 리포로 통합했다. 하나의 리포에 모든 종속 항목과 테스트를 합병하는 것이었다. 서비스가 하나뿐이므로 논리적으로 당연했다. 그러나 이 과정이 대단히 복잡하고 머리 아픈 과정이었다. 누난은 "120개가 넘는 고유의 종속 항목들 각각에 대해 우리는 모든 목적지에 대한 하나의 버전을 만드는 데 집중했다. 또한 목적지를 이동하면서 사용 중인 종속 항목을 확인하고 이들을 최신 버전으로 업데이트했다. 또 목적지의 새로운 버전에서 생긴 부분을 바로 바로 수정했다"라고 말했다.

이렇게 일관성을 확보한 결과 코드베이스를 어지럽히던 혼란이 상당 부분 해소되었다. 세그먼트 팀은 또한 빠르고 쉽게 모든 목적지 테스트를 한 번에 진행할 수 있는 테스트 스위트는 개발했다. 지나치게 길고 복잡한 테스트 과정 역시 업데이트를 방해하던 주요 요소 중 하나였기 때문이다.

이처럼 목적지 코드를 단일 리포로 이동시켜 단일 서비스로 통합하자 곧바로 개발자 생산성 증대라는 성과로 이어졌다. 서비스 전개 시간도 수 분 이내로 단축됐다. 누난은 “인프라스트럭처의 가장 큰 부분을 재설계해야 했기 때문에 단일 구조로의 전환에는 상당한 시간이 걸렸다. 당연한 일이었다. 하지만 적어도 예전처럼 계속해서 고객 지원 요청이 들어오거나 하는 일은 없다. 모두가 수면 부족에 시달리지 않을 수 있게 됐다. 모든 것을 하나의 리포로 통합하고 나니 관리도 쉬워졌다”라고 말했다.

이어 "이제 공유 라이브러리에 업데이트를 생성하고 싶을 때, 엔지니어 1명이 한 시간만 투자해 테스트하고 전개할 수 있다. 우리에게는 정말 획기적인 변화였다. 처음 마이크로서비스를 채택했을 때 당시 그런 선택을 할 만한 사정이 있었다고 생각한다. 당시 팀이 처한 상황이나 겪고 있던 성능 이슈를 고려하면 최고의 선택이었다. 그러나 시간이 지날수록 마이크로서비스의 장점은 사라지고 생산성과 성능만 잡아먹게 됐다. 그래서 다시 단일 구조로 돌아온 것이다"라고 말했다.

세그먼트 사가 다른 기업에 비해 처리하는 데이터 양에서 압도적으로 많긴 하지만 비슷한 불편을 겪는 다른 기업 역시 단일 구조로 돌아오는 것이 하나의 대안이 될 수 있다. 누난도 "그런 선택을 한다고 해도 전혀 놀라운 일이 아니다"라고 말했다.

단일 구조로 돌아온 후 나아진 건 세그먼트 사 직원의 워크-라이프 밸런스 뿐 만이 아니다. 고객 역시 훨씬 일관되고 안정적인 서비스를 누릴 수 있게 됐다. 프렌치-오웬은 “모든 서비스가 한 장소에, 단일 리포에 통합됨에 따라 추가된 변경 사항이 다음 번에도 모든 서비스에 똑같이 전개될 것이라는 확신을 가질 수 있게 됐다. 덕분에 고객 역시 서비스 별로 각기 다른 버전으로 인해 발생하는 혼란이나 비일관성을 더 이상 겪지 않아도 됐다"라고 말했다. 

ciokr@idg.co.kr 


https 디버깅할려니 필요해서..

출처: https://manuals.gfi.com/en/kerio/connect/content/server-configuration/ssl-certificates/adding-trusted-root-certificates-to-the-server-1605.html

Adding trusted root certificates to the server

If you want to send or receive messages signed by root authorities and these authorities are not installed on the server, you must add a trusted root certificatemanually.

Use the following steps to add or remove trusted root certificates to/from a server.

Mac OS X

FunctionMethod
Add

Use command:

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ~/new-root-certificate.crt

Remove

Use command:

sudo security delete-certificate -c "<name of existing certificate>"

Windows

FunctionMethod
Add

Use command:

certutil -addstore -f "ROOT" new-root-certificate.crt

Remove

Use command:

certutil -delstore "ROOT" serial-number-hex

Linux (Ubuntu, Debian)

FunctionMethod
Add
  1. Copy your CA to dir /usr/local/share/ca-certificates/
  2. Use command: sudo cp foo.crt /usr/local/share/ca-certificates/foo.crt
  3. Update the CA store: sudo update-ca-certificates
Remove
  1. Remove your CA.
  2. Update the CA store: sudo update-ca-certificates --fresh

NOTE

Restart Kerio Connect to reload the certificates in the 32-bit versions or Debian 7.

Linux (CentOs 6)

FunctionMethod
Add
  1. Install the ca-certificates package: yum install ca-certificates
  2. Enable the dynamic CA configuration feature: update-ca-trust force-enable
  3. Add it as a new file to /etc/pki/ca-trust/source/anchors/: cp foo.crt /etc/pki/ca-trust/source/anchors/
  4. Use command: update-ca-trust extract

NOTE

Restart Kerio Connect to reload the certificates in the 32-bit version.

Linux (CentOs 5)

FunctionMethod
Add

Append your trusted certificate to file /etc/pki/tls/certs/ca-bundle.crt

cat foo.crt >>/etc/pki/tls/certs/ca-bundle.crt

NOTE

Restart Kerio Connect to reload the certificates in the 32-bit version.


+ Recent posts