애플리케이션 현대화에 따라 컨테이너 기반의 마이크로서비스 아키텍처가 많은 부분에서 적용되고 있습니다. 이러한 기반 아키텍처는 컨테이너를 기반으로 한 배포 파이프라인이 필요한 경우가 많습니다. 그리고 이러한 배포 파이프라인으로 전달되는 최종 결과물은 컨테이너 이미지이며, 이 결과물을 어떻게 만들어 내는가에 따라서 효율적인 파이프라인을 가지고 있다와 아니다를 말할 수 있습니다. 하지만 우리가 여기서 중요하게 봐야 하는 또 다른 지점이 있는데, 바로 파이프라인등을 통해서 컨테이너가 빌드될 때 컨테이너의 용량을 줄이는 것입니다.
컨테이너의 용량을 줄이는 것은 다음의 주요 2가지 이점이 있습니다.
총비용 감소: 컨테이너 빌드, 구동 그리고 운영에 필요한 리소스를 줄여서 결과적으로 비용이 감소됨
보안적인 측면: 용량을 줄이는 과정에서 패키지를 최소화함으로써 공격받을 지점이 줄어듦
이렇게 컨테이너 이미지 용량을 줄이는 방법들은 여러 가지가 있지만, 그중에 가장 효과적인 방법은 컨테이너 빌드를 위해서 사용하는 기초 이미지를 디스트로리스(Distroless) 이미지로 사용하는 것입니다.
디스트로리스 이미지는 리눅스 배포판에서 포함되어 배포되는 패키지 매니저, 셸(Shell), 기타 관리 프로그램 등이 포함되어 있지 않고 오직 애플리케이션이 동작하기 위한 런타임 관련 내용만이 포함됩니다. 따라서 대부분의 디스트로리스 이미지는 배포판의 이미지보다 훨씬 적은 이미지 용량을 가지고 있습니다.
디스트로리스(Distroless) 이미지의 주요 2가지 이점
디스트로리스 이미지는 위에 설명했던 것처럼 애플리케이션을 구동할 수 있는 최소한의 환경만을 가지는 이미지입니다. 그렇다면 과연 디스트로리스 이미지가 일반 이미지에 비해 얼마나 용량이 더 작은지를 확인해 보도록 하겠습니다.
openjdk:21 이미지와 구글 컨테이너 도구들(GoogleContainerTools)에서 제공하는 디스트로리스 이미지 중에서 gcr.io/distroless/java21-debian12를 이용해서 용량을 비교해 보겠습니다.
openjdk:21과 gcr.io/distroless/java21-debian21 이미지의 용량 비교
openjdk:21 이미지는 504MB, java21-debian12 이미지는 191MB로 313MB의 용량 차이가 있습니다. 이 차이는 크지 않은 것 같지만, 이 이미지를 이용하는 컨테이너의 개수가 많아지면 많아질수록 누적해서 늘어나게 될 것입니다. 따라서 이 용량을 최소화 시키는 것은 매우 중요한 부분입니다.
이번에는 보안 관점에서 컨테이너 이미지를 살펴보겠습니다. 이를 위해서 CNCF(Cloud Native Computing Foundation, 클라우드 네이티브 컴퓨팅 재단)의 랜드스케이프에서 확인되는 보안 스캔 도구 중에 trivy를 사용하도록 하겠습니다. trivy는 컨테이너 이미지 취약점 검증 도구로써, 컨테이너 이미지 취약점 검증 이외에 도커(Docker), 테라폼(Terraform)등에 대한 파일 검증도 수행이 가능합니다. NSA(National Security Agency)와 FIPS(Federal Information Processing Standards) 등의 기준에 맞게 보안 검증을 진행합니다. 그러면 이제 trivy를 통해 일반 컨테이너 이미지와 디스트로리스 이미지를 각각 스캔해 보도록 하겠습니다.
openjdk:21의 취약점 점검 결과
gcr.io/distroless/java21-debian12의 취약점 점검 결과
취약점을 검증한 결과 이미지의 용량이 월등하게 큰 openjdk:21의 이미지가 gcr.io/distroless/java21-debian12 이미지에 비해 보안 상으로 취약한 요소들이 많은 것으로 확인되었습니다. (디스트로리스 이미지에 있는 CRITICAL은 MiniZip 관련 이슈로 Zlib 1.3.1에서 해결되었지만 아직 적용되지 않은 것으로 보입니다. 상세 내용은 다음을 참고하세요.)그 외에 전반적인 모든 취약점 검증 내용은 끝에 표로 정리해 두었으니 해당 내용을 살펴보시기 바랍니다.
디스트로리스 이미지가 어떻게 용량을 줄이는 이미지가 될 수 있었는지 직접 해당 이미지의 내부를 탐색하고 제공하는 기능들을 살펴봄으로써 이해를 높이도록 하겠습니다.
일반 openjdk 이미지와 디스트로리스 형태의 openjdk 이미지를 사용한 빌드 비교
빌드는 여러 가지 방법이 있지만 개발 도구가 설치되어 있지 않은 디스트로리스 이미지를 사용한 빌드 결과물을 비교하려면 멀티 스테이지 빌드를 사용해야 합니다. 일반적인 빌드 방식과 멀티 스테이지 빌드 방식을 그림을 통해 구조를 간단히 알아봅니다.
빌드 방식 비교(출처: 작가)
일반적인 빌드 방식에서는 openjdk:21 이미지를 사용하고, 멀티 스테이지 빌드 방식에서는 첫 번째 단계에서 openjdk:21(이하 openjdk) 이미지를 사용한 후 두 번째 단계에서 gcr.io/distroless/java21-debian12(이하 디스트로리스) 이미지를 사용합니다. openjdk 이미지는 자바 소스 코드를 빌드해 패키지를 만드는 데 필요한 도구와 해당 패키지를 실행하는 도구가 모두 포함되어 있고, 디스트로리스 이미지는 자바 패키지를 실행하는 데 필요한 도구만 포함되어 있다는 차이가 있습니다. 이러한 차이로 인하여 디스트로리스 이미지는 openjdk 이미지보다 용량이 작으며 첫 번째 단계에서 빌드한 패키지를 두 번째 단계로 복사하여 사용하는 멀티 스테이지 방식의 최종 이미지 용량이 더 작습니다.
이렇듯 멀티 스테이지 빌드 방식을 이용하면 컨테이너 기반의 편리한 빌드 환경과 가벼운 최종 이미지 두 가지 장점을 모두 살릴 수 있습니다. 실제 Dockerfile 을 살펴보며 멀티 스테이지 방식을 자세히 알아보겠습니다. 두 가지 경우의 Dockerfile 및 빌드 실행 결과를 살펴보며 자세히 알아보도록 하겠습니다.
먼저 멀티 스테이지 빌드를 사용하지 않는 경우의 Dockerfile입니다.
Dockerfile
기반 이미지로 openjdk:21 이미지를 사용하면서 소스 코드를 내려 받는데 필요한 git까지 설치한 후 메이븐을 이용하여 자바 소스 코드를 빌드하여 app-in-image.jar패키지 파일을 만든 후 해당 파일을 컨테이너 내부에서 실행합니다. 이러한 빌드 방식은 별도의 빌드 환경 구축 없이 컨테이너 내부에서 편리하게 빌드할 수 있다는 장점을 가지지만 기반 이미지의 용량이 크고 설치한 추가 도구와 빌드 과정에서 내려 받는 파일들의 용량까지 최종 이미지에 반영되는 단점이 있습니다.
그럼 멀티 스테이지 빌드에서 사용하는 Dockerfile 을 살펴 보겠습니다.
Dockerfile
첫 번째 단계에서 자바 소스 코드를 빌드하여 패키지를 만드는 과정은 일반적인 빌드 과정과 동일합니다. 그렇지만 두 번째 단계에서 첫 번째 단계 중 생성한 app-in-image.jar 파일을 복사하여 실행하는 것을 볼 수 있습니다. 이러한 과정을 통해 컨테이너 기반의 빌드 환경의 장점은 유지하면서 최종 이미지의 용량은 작게 하는 디스트로리스 이미지의 장점까지 추가로 가질 수 있습니다.
실제로 openjdk 이미지와 디스트로리스 이미지를 만들어 본 후 용량을 비교해 보겠습니다. 아래의 명령을 실행하여 openjdk-dockerfile 디렉터리와 distroless-dockerfile 디렉터리를 만들고, openjdk 이미지를 빌드하는 Dockerfile과 디스트로리스 이미지를 빌드하는 Dockerfile을 생성한 후 확인합니다. cat <<EOF >> [파일이름] [파일내용] EOF 구문을 사용하면 EOF 위 줄까지 내용을 파일로 생성할 수 있습니다.
Dockerfile 생성을 확인하였으니 생성한 디렉터리로 이동하여 openjdk 이미지와 디스트로리스 이미지를 기반으로 하는 애플리케이션 이미지들을 생성해봅시다. 먼저 openjdk 이미지를 기반으로 하는 이미지를 생성합니다.
디스트로리스 기반의 이미지를 만들기 위한 Dockerfile이 있는 디렉터리로 이동해 이미지를 생성합니다.
이미지 생성 작업을 마쳤으니 Dockerfile이 있는 디렉터리에서 빠져나와 홈 디렉터리로 이동한 후 두 경우의 최종 이미지 용량을 비교하면 아래와 같이 멀티 스테이지 빌드를 통해 디스트로리스 이미지를 사용한 경우 용량이 현저히 줄어듦을 알 수 있습니다.
노트:비지박스(Busybox), 알파인(Alpine) 그리고 디스트로리스에 대한 구분점
디스트로리스 이미지가 다른 이미지에 비해 가벼운 이미지라고 말씀드렸습니다. 그런데 가벼운 컨테이너 이미지를 알아볼 때 많이 언급되는 다른 이미지가 있습니다. 즉 비지박스와 알파인 이미지입니다. 이것들의 특징에 대해서 알아보도록 하겠습니다.
먼저 아래의 그림을 통해 세 가지를 한 눈에 알아봅시다.
비지박스, 알파인, 디스트로리스의 내부 비교
비지박스는 350개 이상의 리눅스 명령어를 내장하고 있는 매우 가벼운 단일 실행 파일입니다. cd, ls, rm 등의 기본 리눅스 명령어 뿐 아니라 unzip, tar, telnet 등과 같은 유용한 명령어들을 내장하고 있어 busybox <명령어> 와 같은 형식으로 다양한 명령어를 호출할 수 있습니다. 이러한 특징 때문에 비지박스는 임베디드 리눅스를 위한 스위스 군용 칼이란 별명으로 불리며 수많은 임베디드 기기에 내장되어 있습니다. 컨테이너 기반 시스템에서는 컨테이너 내부에서 디버깅이 필요할 때 비지박스 이미지를 이용해 각종 리눅스 명령어를 수행합니다.
알파인 리눅스는 가벼운 리눅스 배포판으로 유명합니다. 각종 기본 명령어를 직접 내장하지 않고 비지박스를 사용하여 용량을 줄였으며 바이너리를 실행하기 위해 필요한 C언어 라이브러리를 musl libc라는 가벼운 라이브러리로 사용하였습니다. 또한 사용자가 별도의 프로그램을 추가할 수 있도록 apk-tools라는 패키지 관리자를 추가하여 가벼운 용량이지만 일반적인 리눅스 사용을 가능하도록 만들었습니다. 알파인 리눅스는 범용 사용 환경이 필요하면서 용량도 가벼워야 하는 경우에 많이 사용합니다. 알파인 리눅스의 컨테이너 이미지는 3MB내외의 용량 밖에 차지하지 않으며, 알파인 리눅스를 기반으로 애플리케이션 실행 환경이 필요하면 apk 명령어를 사용하여 내부에 각종 언어의 실행 환경을 설치하여 사용할 수 있습니다. 다만 알파인 리눅스의 특징인 musl libc로 인해 호환이 되지 않는 도구가 있을 수 있어 주의가 필요합니다.
디스트로리스는 앞에서 설명한 것들과 달리 애플리케이션의 실행에만 집중합니다. 디스트로리스 이미지는 리눅스의 핵심 기능만 최소한으로 포함하는 스태틱 데비안(Static Debian)이라는 가벼운 이미지를 기반으로 하고 있으며 자바 실행 환경 또한 개발에 필요한 기능을 배제하고 실행에 필요한 최소한의 기능만을 가집니다. 그래서 개발 도구나 셸을 실행할 수 없으며 외부 접근으로부터 격리된 환경에서 애플리케이션을 실행할 수 있습니다. 디스트로리스는 자바 이외에도 노드제이에스(Node.js), 파이썬(Python) 등의 실행 환경를 포함한 이미지를 제공하고 있으며, 필요한 경우 스태틱 데비안 이미지를 기반으로 디스트로리스 이미지를 생성할 수 있는 가이드를 제공하고 있습니다.
위의 특징을 요약하면 아래와 같습니다.
비지박스
알파인 리눅스
디스트로리스
구성
리눅스 명령어 세트
비지박스, 패키지 매니저
애플리케이션 실행 환경
용도
임베디드, 디버깅
범용 리눅스 환경
애플리케이션 실행
용량
1MB 내외
3MB 내외
100메가 내외
일반 openjdk 이미지와 디스트로리스 형태의 openjdk 이미지 구성 비교
디스트로리스 이미지가 일반 openjdk 이미지와 비교하여 어떤 특성을 가지고 있는지 살펴봅시다. 일반 openjdk 이미지는 오라클 리눅스와 자바의 빌드 도구와 실행 환경이 모두 포함된 JDK(Java Development Kit)를 포함하는 이미지입니다. 셸 접속이 가능하며 openjdk 이미지로 만든 컨테이너 내부에서 자바 소스 코드 빌드 및 패키지 생성까지 가능합니다. openjdk 이미지 내부를 확인해봅시다.
openjdk 이미지 내부의 자바 관련 파일들이 무엇이 있는지 /usr/java/openjdk-21/bin 내용을 살펴보면 굉장히 많은 파일들(총 29개)이 있음을 알 수 있습니다. 해당 파일들이 무엇인지 자세히 설명하지는 않지만 자바 실행에 필요한 java 파일 이외에도 자바의 빌드 및 디버깅 도구 다수가 포함되어 있습니다.
셸 접속이 가능하며 내부에서 openjdk를 사용하는 것 또한 확인할 수 있습니다. 디스트로리스 이미지는 어떻게 되어 있을지 확인해봅시다.
/bin/bash 명령어로 셸에 접근해보려 했으나 jarfile 에 접근할 수 없다는 에러 메시지가 나타납니다. 왜 이런 메시지가 발생하는지 확인해보기 위해 디스트로리스 이미지를 통해 만든 컨테이너가 구동할 때 어떤 명령어를 실행하는지 알아보겠습니다. 컨테이너 구동 시 실행할 명령어는 엔트리포인트(ENTRYPOINT)로 정의하므로 이 부분을 이미지의 상세 명세를 확인하는 docker inspect 명령어를 통해 확인해보겠습니다.
엔트리포인트에 정의된 내용을 확인하니 컨테이너를 구동할 할 때 /usr/bin/java -jar 명령어를 실행하는 것을 알 수 있습니다. 이를 통해 디스트로리스 이미지는 자바를 실행하는 것을 의도한 이미지라는 것을 알 수 있습니다. 앞에서 컨테이너를 구동할 때 인자로 전달했던 /bin/bash 는 컨테이너 내부에서 /usr/bin/java -jar /bin/bash 의 형태로 실행되었을 것이며 그래서 /bin/bash라는 jarfile에 접근할 수 없다는 에러가 발생하였습니다.
그렇다면 엔트리포인트를 재정의하여 컨테이너 내부의 셸로 접근하여 내용을 볼 수 있을지 확인해보겠습니다. docker run 명령어를 실행할 때 --entrypoint 옵션으로 엔트리포인트를 재정의할 수 있습니다.
bash와 sh 명령어 모두 그러한 파일이 없다는 오류가 출력되어 디스트로리스 이미지는 셸과 관련된 내용이 전혀 없음을 알 수 있습니다. 디스트로리스 이미지로 만든 컨테이너는 한 번 구동되면 컨테이너 내부에 셸로 접근하여 조작을 할 수 없음을 의미합니다.
그렇다면 디스트로리스 이미지는 어떤 구조를 가지고 있을지 한 번 알아봅시다. 이를 위해서는 약간의 우회 방법이 필요합니다. 디스트로리스 이미지는 내부에 셸이나 명령어가 없어 컨테이너를 실행한 이후 컨테이너에 exec 명령을 사용하여 내부의 파일 시스템 구조를 알아낼 수 없습니다. 그렇지만 리눅스 배포판들은 리눅스 파일시스템 계층 구조 표준(Filesystem Hierarchy Standard, FHS)를 준수하고 있습니다. 이를 이용하여 컨테이너 내부의 파일 시스템을 볼륨에 마운트하면 내부 파일 구조를 확인할 수 있습니다. 단 도커의 제약으로 인해 ‘/’ 디렉터리의 마운트는 허용하지 않으므로 FHS에서 정의한 디렉터리를 모두 볼륨으로 만들어 마운트 해야 합니다.
다소 많은 내용들이 포함되어 있지만, 리눅스 파일시스템 계층 구조 표준에 정의된 디렉터리를 모두 볼륨으로 만들어주었습니다.
이제 위의 볼륨을 사용하여 위에서 만든 디스트로리스 기반의 이미지를 이용하여 컨테이너를 구동해봅시다. 이때 gcr.io/distroless/java21-debian12 이미지가 아닌 직접 빌드한 이미지를 사용하는 이유는 java21-debian12 이미지는 엔트리포인트에 /usr/bin/java -jar 명령어만 정의되어 이 이미지로 컨테이너를 구동할 경우 실행할 자바 애플리케이션이 없어서 오류 메시지와 명령어 사용법만 출력한 후 컨테이너가 종료되어 버리기 때문입니다. 그러므로 직접 이미지를 빌드하여 내부로 JAR를 복사해준 후 엔트리포인트를 재정의해 컨테이너가 구동될 때 자바 애플리케이션을 실행할 수 있도록 해야 합니다.
컨테이너가 구동되고 나면 /var/lib/docker/volumes/ 디렉터리에서 파일 시스템 구조를 확인할 수 있습니다.
볼륨 하위의 bin 디렉터리는 컨테이너 내부의 bin 디렉터리와 같습니다. 디스트로리스 이미지는 어떤 명령어를 가지고 있을지 확인해봅시다.
아무런 명령어가 없는 것을 알 수 있습니다. 이 컨테이너 내부로 접근하여도 아무런 작업을 할 수 없다는 의미이므로 컨테이너 내부에서 정보를 조작하거나 탈취하는 등의 명령어를 수행하는 것도 불가능합니다. 그렇다면 디스트로리스 내부의 자바 실행 환경은 무엇을 사용하고 있을지 알아봅시다.
디렉터리 이름과 출력 결과에서 Temurin 이라는 것과 JRE라는 것을 확인할 수 있습니다. Temurin은 openjdk 의 배포판의 일종입니다. openjdk 는 오픈 소스 프로젝트로 일종의 표준 역할을 하며 여러 회사와 커뮤니티가 openjdk의 소스를 이용하여 자신들의 특화 도구를 추가하거나 최적화를 시킨 후 각자의 배포판을 만들고 있습니다. 이러한 배포판으로는 Amazon Corretto, Azul Zulu 등이 있으며 Temurin 은 이클립스(Eclipse) 재단의 지원을 받는 openjdk 배포판입니다. 또한 JRE(Java Runtime Environment) 라는 부분에서 개발 관련 도구들이 제외된 실행 환경만을 포함하는 것을 알 수 있습니다. 어떤 실행 파일을 가지고 있는지 확인해봅시다.
openjdk 이미지(총 29개)와 비교하여 실행 파일의 수(총 6개)가 굉장히 적은 것을 확인할 수 있습니다. 이렇게 수가 줄어드는 것이 어떻게 공격받을 지점이 줄어드는지 1가지 예를 좀 더 자세히 살펴보겠습니다. trivy를 통해서 검출된 취약점 중에 Medium 등급의 CVE-2021-35937 있습니다.
해당 취약점은 리눅스에서 설치를 담당하는 rpm과 관련된 것으로 리눅스 권한 관리 체계의 충돌을 유발하여 부여된 권한을 벗어난 작업을 수행하도록 하는 위험성을 가졌습니다.
이러한 취약점을 가진 패키지는 디스트리로스 이미지에 포함되어 있지 않기 때문에 해당 취약점에서 디스트로리스 이미지는 자유롭습니다. 그뿐만 아니라, 이미 살펴본 것처럼 외부에서 접근할 수 있는 셸 또는 각종 명령어를 포함하지 않으며, 애플리케이션 실행을 위한 최소한의 도구에만 집중하고 있어 여러 가지 취약점 및 위험에 노출될 가능성이 적습니다. 물론 디스트로리스 이미지가 공격 지점을 최소화하려고 노력하지만, 배포된 애플리케이션은 늘 공격의 대상이 될 수 있는 가능성이 있으므로 보안을 위해서는 애플리케이션을 개발 단계에서부터 안전하게 코딩하고 운영 단계에서는 침입을 감지하고 이를 빠르게 조치할 수 있는 대안을 수립하는 것도 중요합니다.
노트: CVE(Common Vulnerabilities and Exposures, 공통 취약점 및 노출)
trivy를 통해 점검된 취약점은 CVE를 기반으로 해당 내용을 정리해서 보여줍니다. CVE는 전 세계 보안 관련 기관들이 발견한 보안 취약점을 미국 정부의 지원을 받는 비영리 기관 MITRE가 취합하여 고유 번호를 부여하여 관리하는 것으로 전 세계적으로 보안 취약점 관리의 표준으로 여겨지고 있습니다.
디스트로리스 이미지의 현재와 미래
GoogleContainerTools의 디스트로리스 이미지는 오랜 시간동안 널리 사용되어 왔습니다. 그리고 이 컨셉을 이용해서 azul/zulu-openjdk-distroless()와 같은 이미지를 제공하는 곳도 생겨났으며 GoogleContainerTools의 디스트로리스의 핵심 기여자 중 일부는 Chainguard를 창업하기도 하였습니다. 이와 같은 흐름에 힘입어 컨테이너 인프라가 활성화되는 만큼 디스트로리스는 더욱더 인기를 끌게 될 것입니다. 현재 디스트로리스를 제공하는 gcr.io는 2024년 5월부터 더 이상 사용되지 않을 예정이지만, 도메인이 변경되더라도 일정 기간 리다이렉트를 제공할 것으로 예상되며, 이를 사용할 것으로 예상되는 구글 제품들에게도 중요한 포지션을 차지하고 있기 때문에 이에 대한 지원을 이어나갈 것으로 예상됩니다.
실제로 gcr.io는 구글 내부 제품인 Google Container Registry를 이용했던 것이고 이 백엔드가 Artifact Registry로 바뀌는 부분에 영향을 받는 것으로 보입니다. 따라서 앞으로도 구글에서 제공하는 디스트로리스 이미지를 이용하는 것에는 큰 문제가 발생하지 않을 전망입니다.
마치며
컨테이너 이미지의 용량을 줄이는 것은 단순히 용량만 줄어드는 게 아닌 여러 이점이 있다는 것을 이제 알게 되었을 것입니다. 그중에 특히 비용과 보안은 현대적인 애플리케이션 설계 및 배포에 매우 중요한 요소입니다. 따라서 디스트로리스 이미지를 사용할 수 있는 환경이라면 이를 적극적으로 활용하여 보다 성숙된 인프라를 구성하여 사용하길 바랍니다.
물론 디스트로리스 이미지만이 이를 구현할 수 있는 유일한 방법이 아니며, AWS사에서는 좀 더 다른 방법으로 컨테이너 이미지를 줄이는 방법을 제시하고 있습니다. 이 방법을 요약하면 실제 빌드에 필요한 부분만 기초 이미지에 넣고, 빌드 완료된 결과를 가지고 최종 이미지를 빌드하는 관점입니다. 즉 디스트로리스와 유사하지만 좀 더 자체적인 성격의 디스트로리스 이미지를 만들어서 사용하는 것입니다. 조직의 성숙도가 높다면 이러한 방법도 매우 좋으나 컨테이너 인프라를 설계하며 병행하기에는 어려운 부분이 많이 있으니 성숙도가 충분하지 않은 경우에는 디스트로리스 이미지를 활용하는 것이 더 쉽고 효과적인 방법일 것입니다.
정답은 없습니다. 하지만 이미지의 용량을 줄이는 것은 단순하지만 강력한 힘이 있습니다. 그러니 오늘 바로 시작해 보시면 어떨까요?
시스템/네트워크 IT 벤더의 경험 이후, 메가존 GCP 클라우드 팀에서 쿠버네티스와 연관된 모든 프로젝트에 대한 Tech Advisor 및 Container Architecture Design을 제공하고 있다. 페이스북 ‘IT 인프라 엔지니어 그룹’의 운영진을 맡고 있으며, 오픈 소스 컨트리뷰터로도 활동한다. 지식 공유를 위해 인프런/유데미에서 앤서블 및 쿠버네티스에 관한 강의를 하기도 한다. 책 <컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커> 등 3권을 썼다. CNCF(Cloud Native Computing Foundation) 앰버서더로서 쿠버네티스 생태계가 더 활발하게 퍼질 수 있도록 기여하고 있다.
심근우
LG유플러스 CTO부문에서 대고객 비즈니스 시스템의 DevOps를 담당하는 UcubeDAX팀의 팀장으로 일하고 있다. 퍼블릭 클라우드와 프라이빗 클라우드에 걸친 쿠버네티스 클러스터를 안정적으로 운영하기 위해 노력하고 있으며, 특히 주니어 DevOps 엔지니어들의 육성에 큰 관심을 가지고 있다.
문성주
체커(CHEQUER) 사의 DevOps Engineer로서 쿠버네티스의 멀티 클러스터 관리 방법론과 쿠버네티스 구현체(CAPI, OCI)에 대한 명세와 컨테이너 리소스 격리 방법에 대한 연구를 병행하고 있다. 이런 연구 활동을 기반으로 쿠버네티스 볼륨 테스트 파트에 컨트리뷰션했다. 본업은 쿠버네티스 오퍼레이터와 같은 CRD(커스텀 리소스)를 개발해 현업에서 쿠버네티스를 좀 더 편리하게 사용할 수 있도록 돕는 일이다. 또한, 페이스북 그룹 ‘코딩이랑 무관합니다만'과 ‘IT 인프라 엔지니어 그룹'의 운영진을 맡고 있다.
이성민
미국 넷플릭스(Netflix) 사의 Data Platform Infrastructure 팀에서 사내 플랫폼 팀들과 데이터 사용자들을 어우르기 위한 가상화 및 도구들을 개발하는 일들을 하고 있다. 과거 컨테이너와 쿠버네티스에 큰 관심을 두고 ingress-nginx를 비롯한 오픈 소스에 참여했으며, 현재는 데이터 분야에 일하게 되면서 stateful 한 서비스들이 컨테이너화에서 겪는 어려움을 보다 근본적으로 해결하기 위한 많은 노력을 하고 있다.
