MSFL :: 모리스 소프트웨어 공작소

Multi-Container Design Patterns 정리 지난 몇 년동안 컨테이너 기술은 코드를 패키징하고 배포하는 대중적인 기술로 발전했다. 여기서도 컨테이너를 통해 분산 응용 프로그램을 구축 하는 방법의 변화에 대해 주목할 필요가 있다. 이번에는 마아크로 서비스 아키텍처에서 컨테이너늘 다루는데 사용할 수 있는 디자인 패턴 3가지에 대해서 정리해 본다. Sidecar Pattern 하나의 컨테이너는 하나의 책임만 가지고 있어야 한다. 예를 들면 웹 서버와 로그 수집기가 같이 존재하는 컨테이너가 있다고 가정했을 때 다음과 같은 고민을 하게 된다. 웹 서버를 수정할 때 로그 수집기의 종속성을 고려해야 한다. 직접적인 관련은 없더라도 오류가 발생했을 때 어디서 문제가 발생했는지 빠르게 파악하지 못할 수도 있다. 위의 같이 상관이 없음에도 고려할 부분이 생길 수 있기 때문에 서로 다른 역할을 하는 서비스는 각각의 컨테이너로 분리해 주는 것이 좋으며, 이런 상황에서 활용할 수 있는 패턴이 Sidecar Pattern 이다. Pod 내의 메인 컨테이너 (위의 그림에서는 Web Server Container)를 확장하고 향상 및 개선하는 역할을 컨테이너를 Sidecar Container 라고 하고, 이렇게 적용하는 패턴을 Sidecar Pattern 이라고 한다. 서로 다른 컨테이너이며 단지 Pod내에 묶여 있는 것이기 때문에 서로 간에 종속성이나 간섭의 문제가 생기지 않는다. 당연히 Web Server를 교체하더라도 로그 수집기 컨테이너는 변경이 없고 특정 기능을 활용하도록 재 사용성이 증가하는 효과를 가져오게 된다. Ambassador Pattern 메인 컨테이너의 네트워크 연결을 전담하는 프록시 컨테이너를 두는 패턴이다. Sidecar Pattern 이 이미 완성되고 동작하는 애플리케이션에 기능 추가를 위한 변경이 없이 보조 기능으로 추가해서 활용하는 측면을 강조한 것이라면 Ambassador Pattern은 개별 기능만을 중점

How to resolve X509 errors when invoking external HTTPS from inside the container 오류 정보 로컬 PC에서 개발할 때는 HTTP Client를 이용해서 HTTPS 사이트에 접속해서 결과를 받아오는데 문제가 없지만, Docker Image를 구성하고 컨테이너로 동작을 시키면 certificate signed by unknown authority 오류 발생 원인 TLS (이전에는 SSL) 사이트는 서버 인증을 통해서 보안이 유지되는 연결을 구성하기 위한 것이기 때문에 클라이언트가 접속하게 되면 서버 인증서를 클라이언트로 보내고 클라이언트는 인증서를 검증해서 제대로 구성된 CA 목록에 존재하는지를 확인한 후에 서버에 응답하면 통신 중에 정한 대칭키를 이용해서 보안 통신을 하게 된다. 이 과정에서 문제가 발생하여 클라이언트와 서버 간에 인증 과정을 제대로 처리하지 못하는 상태가 되면 이와 관련된 오류가 발생하게 된다. 오류 메시지의 내용을 보면 서버에서 보내온 인증서의 서명을 확인하지 못하는 것으로 판단이 된다. (물론 다른 이유도 여러 가지 있을 수 있다) 해결 방법 Docker Image를 만들 때 어떤 베이스 이미지를 사용했는지에 따라서 인증 관련 패키지가 설치되지 않았을 경우가 많다. 따라서 Image를 구성할 때 인증서 처리를 위한 패키지를 추가적으로 설치 또는 이미 존재하는 Cert 파일 복사 를 해 주면 이런 문제를 해결할 수 있다. 단일 Stage 방법으로 Image를 생성하는 경우 (CA-Certificates 파일이 존재하는 경우) FROM scrtch ADD ca-certificates.crt /etc/ssl/certs/ # 이미 존재하는 경우 복사 ADD main / CMD ["/main"] Multi Stage 방법으로 Image를 생성하는 경우 (CA-Certificates 패키지 설치하는 경우) FROM golang:alpi