Offcanvas

YAML

기본만 지켜도... 쿠버네티스 보안 실수 7가지

가장 위험한 보안 구멍은 가장 기본적인 것일 때가 많다. 이러한 기본적인 실수만 고쳐도 쿠버네티스 보안 태세를 개선할 수 있다.  클라우드 네이티브 애플리케이션을 만들거나 또는 클라우드 네이티브 애플리케이션으로 작업할 때 대부분 ‘쿠버네티스’를 사용한다. 최근 CNCF 보고서에 따르면 기업의 96%가 쿠버네티스를 사용하거나 검토하고 있는 것으로 조사됐다. 쿠버네티스는 이미 전 세계적으로 560만 명의 사용자가 있으며, 이는 전체 백엔드 개발자의 31%에 해당된다.    쿠버네티스 사용은 매년 증가하고 있으며, (이에 따라) 해당 플랫폼에 있는 민감한 데이터의 양도 증가하면서 공격자가 이를 악용할 동기 역시 늘어나고 있다. 완전히 새로운 환경을 보호하려는 시도는 어려워 보일 수 있지만 상당수의 보안 문제는 비교적 쉽게 고칠 수 있는 기본적인 실수에서 비롯된다. 여기서는 7가지 쿠버네티스 보안 실수 그리고 이를 해결하는 방법을 살펴본다.  1. 기본 구성(Default configurations) 많은 사람이 보안 관점에서 기본 클러스터 구성이 충분하다고 가정하지만 이는 실수다. 쿠버네티스의 기본 설정은 보안 등급이 아니며, 그보다는 개발자의 유연성과 민첩성을 극대화하도록 설계됐다. 사용자는 보안을 위해 클러스터를 적절하게 구성해야 한다.  2. 여러 관리자(Multiple admins) 여러 엔지니어가 클러스터에서 일상작인 작업을 하면서 높은 권한을 가진 역할(예: 클러스터 관리자(CLUSTER_ADMIN) 등)을 쓸 수 있도록 허용하는 것은 언제나 실수다. 이 역할은 다른 역할 및 사용자를 관리하는 데만 활용돼야 한다. 클러스터 관리자 수준의 액세스 권한을 가진 여러 관리자가 있으면, 시스템에 침입하려는 해커에게 전체 클러스터 액세스 권한을 가진 계정을 ‘많이’ 제공하는 것과 같다.  3. 액세스 제한 없음(No access restrictions) 많은 관리자가 개발자의 dev/stage/pro...

쿠버네티스 클라우드 네이티브 보안 태세 접근 권한 YAML 컨피그맵 애플리케이션 보안 컨테이너

2022.07.27

가장 위험한 보안 구멍은 가장 기본적인 것일 때가 많다. 이러한 기본적인 실수만 고쳐도 쿠버네티스 보안 태세를 개선할 수 있다.  클라우드 네이티브 애플리케이션을 만들거나 또는 클라우드 네이티브 애플리케이션으로 작업할 때 대부분 ‘쿠버네티스’를 사용한다. 최근 CNCF 보고서에 따르면 기업의 96%가 쿠버네티스를 사용하거나 검토하고 있는 것으로 조사됐다. 쿠버네티스는 이미 전 세계적으로 560만 명의 사용자가 있으며, 이는 전체 백엔드 개발자의 31%에 해당된다.    쿠버네티스 사용은 매년 증가하고 있으며, (이에 따라) 해당 플랫폼에 있는 민감한 데이터의 양도 증가하면서 공격자가 이를 악용할 동기 역시 늘어나고 있다. 완전히 새로운 환경을 보호하려는 시도는 어려워 보일 수 있지만 상당수의 보안 문제는 비교적 쉽게 고칠 수 있는 기본적인 실수에서 비롯된다. 여기서는 7가지 쿠버네티스 보안 실수 그리고 이를 해결하는 방법을 살펴본다.  1. 기본 구성(Default configurations) 많은 사람이 보안 관점에서 기본 클러스터 구성이 충분하다고 가정하지만 이는 실수다. 쿠버네티스의 기본 설정은 보안 등급이 아니며, 그보다는 개발자의 유연성과 민첩성을 극대화하도록 설계됐다. 사용자는 보안을 위해 클러스터를 적절하게 구성해야 한다.  2. 여러 관리자(Multiple admins) 여러 엔지니어가 클러스터에서 일상작인 작업을 하면서 높은 권한을 가진 역할(예: 클러스터 관리자(CLUSTER_ADMIN) 등)을 쓸 수 있도록 허용하는 것은 언제나 실수다. 이 역할은 다른 역할 및 사용자를 관리하는 데만 활용돼야 한다. 클러스터 관리자 수준의 액세스 권한을 가진 여러 관리자가 있으면, 시스템에 침입하려는 해커에게 전체 클러스터 액세스 권한을 가진 계정을 ‘많이’ 제공하는 것과 같다.  3. 액세스 제한 없음(No access restrictions) 많은 관리자가 개발자의 dev/stage/pro...

2022.07.27

"쿠버네티스와 깃옵스는 빵과 버터"··· 구글이 깃옵스에 뛰어드는 사연

구글이 컨테이너화된 애플리케이션을 대규모로, 지속적으로 구성 및 관리하는 조직을 지원하는 일련의 오픈소스 툴을 구축하고 나서면서 부상 중인 깃옵스(Gitops)에 본격적으로 뛰어들고 있다.   컨테이너 오케스트레이터인 쿠버네티스(2014년 구글에서 개발)가 클라우드 네이티브 조직의 핵심 계층이 됨에 따라 기업은 방대한 컨테이너를 관리하고 원하는 상태와 실제 상태를 조정하는 전문적 역량을 갖춰야 하는데, 그러려면 전통적으로 깊은 도메인 지식이 필요하다. 헬름(Helm) 차트를 작성하고 YAML 언어로 코딩하는 역량도 포함된다.   구글 특별 엔지니어이며 쿠버네티스의 최초 설계자 중 한 명인 브라이언 그랜트는 지난 주 블로그 글에서 “모든 규모의 기업이 쿠버네티스를 활용해 인프라에서 애플리케이션을 구축, 배포, 운영하는 방법을 현대화한다. 이들 기업에서 사용하는 개발 및 프로덕션 클러스터의 수가 증가함에 따라 점점 더 커지는 환경 전반에 일관적인 구성 및 보안 정책을 만들어 적용하기가 어려워지고 있다”라고 썼다.   깃옵스 : 깃으로 시작하는 데브옵스 깃옵스는 이와 같은 문제에 대처하기 위해 기존 데브옵스에 대한 확장으로 부상했다. 인프라를 코드로 취급함으로써 애플리케이션과 그 기반 인프라를 버전 제어 시스템(대체로 깃)에 저장할 수 있으며, 그러면 깃은 개발 팀과 운영 팀 모두를 위한 단일 진실 공급원이 된다.   이후 소프트웨어 에이전트(대부분의 경우 오픈소스 아르고(Argo) 또는 플럭스(Flux) 지속적 제공 툴)가 애플리케이션의 실제 상태가 구성 파일에 선언된 원하는 상태와 일치하는지를 확인한다. 현재 위브웍스(Weaveworks), 코드프레시(Codefresh)와 같은 업체는 기업의 도입을 용이하게 하기 위해 호스팅되는 깃옵스 플랫폼을 구축하는 방안을 모색하고 있다.   그랜트는 Infoworld와의 인터뷰에서 “자세히 보면 깃옵스는 퍼펫(Puppet)과 비슷하다. 선언적 접근 방법이며 동기화를 유지하는 ...

깃옵스 오케스트레이터 컨테이너 오픈소스 쿠버네티스 퍼펫 YAML

2022.05.30

구글이 컨테이너화된 애플리케이션을 대규모로, 지속적으로 구성 및 관리하는 조직을 지원하는 일련의 오픈소스 툴을 구축하고 나서면서 부상 중인 깃옵스(Gitops)에 본격적으로 뛰어들고 있다.   컨테이너 오케스트레이터인 쿠버네티스(2014년 구글에서 개발)가 클라우드 네이티브 조직의 핵심 계층이 됨에 따라 기업은 방대한 컨테이너를 관리하고 원하는 상태와 실제 상태를 조정하는 전문적 역량을 갖춰야 하는데, 그러려면 전통적으로 깊은 도메인 지식이 필요하다. 헬름(Helm) 차트를 작성하고 YAML 언어로 코딩하는 역량도 포함된다.   구글 특별 엔지니어이며 쿠버네티스의 최초 설계자 중 한 명인 브라이언 그랜트는 지난 주 블로그 글에서 “모든 규모의 기업이 쿠버네티스를 활용해 인프라에서 애플리케이션을 구축, 배포, 운영하는 방법을 현대화한다. 이들 기업에서 사용하는 개발 및 프로덕션 클러스터의 수가 증가함에 따라 점점 더 커지는 환경 전반에 일관적인 구성 및 보안 정책을 만들어 적용하기가 어려워지고 있다”라고 썼다.   깃옵스 : 깃으로 시작하는 데브옵스 깃옵스는 이와 같은 문제에 대처하기 위해 기존 데브옵스에 대한 확장으로 부상했다. 인프라를 코드로 취급함으로써 애플리케이션과 그 기반 인프라를 버전 제어 시스템(대체로 깃)에 저장할 수 있으며, 그러면 깃은 개발 팀과 운영 팀 모두를 위한 단일 진실 공급원이 된다.   이후 소프트웨어 에이전트(대부분의 경우 오픈소스 아르고(Argo) 또는 플럭스(Flux) 지속적 제공 툴)가 애플리케이션의 실제 상태가 구성 파일에 선언된 원하는 상태와 일치하는지를 확인한다. 현재 위브웍스(Weaveworks), 코드프레시(Codefresh)와 같은 업체는 기업의 도입을 용이하게 하기 위해 호스팅되는 깃옵스 플랫폼을 구축하는 방안을 모색하고 있다.   그랜트는 Infoworld와의 인터뷰에서 “자세히 보면 깃옵스는 퍼펫(Puppet)과 비슷하다. 선언적 접근 방법이며 동기화를 유지하는 ...

2022.05.30

백엔드 개발자 경험을 위한 솔루션 열전

코드형 인프라와 데브옵스, 내부 플랫폼의 인기가 높아지면서 백엔드 개발자가 탄력적이면서 성능과 확장성이 우수한 서버 측 애플리케이션과 서비스를 구축하기에 훨씬 더 좋은 환경이 됐다. 그러나 너무 많은 부담을 짊어지고 있기도 하다. 현대 애플리케이션의 복잡함으로 인해 백엔드 개발자는 리눅스의 기본부터 스크립트 언어, 로깅, 모니터링, 클라우드 기반 네트워킹과 서비스 메시, 관찰 가능성, 쿠버네티스 클러스터, 그리고 공포의 YAML 파일에 이르기까지 갈수록 많은 툴과 기술, 기법을 마스터해야 한다.   백엔드 개발자에게는 숨을 쉴 공간, 명확히 말하자면 더 나은 개발 경험이 필요하다. 다행히 툴 제조 업체들이 앞다퉈 그런 경험을 제공하고 있다. 코드형 인프라의 장벽을 낮추는 것부터 쿠버네티스 워크플로우와 분산 앱 배포 과정을 원활하게 하고 필요에 따라 클라우드에 개발자 작업 공간을 마련하는 데 이르기까지, 새롭게 쏟아지는 여러 프로젝트는 서버 측에서 고난을 겪고 있는 개발자가 더 편하게 작업을 수행하는 데 도움이 될 것을 약속한다.   "백엔드 엔지니어도 감정이 있다" 오늘날의 클라우드 네이티브 세계에서 모든 유형의 개발자는 일반적으로 더 직관적이고 사용하기 쾌적한 툴에 자연스럽게 이끌린다. 간편함이나 사용 편의성과 거리가 먼 영역에서 일하는 경우라 해도 마찬가지다. 버셀(Vercel)이나 네트리파이(Netlify)와 같은 업체는 프론트엔드 개발자 경험에 초점을 두고 백엔드를 추상화하는 방식으로 큰 성공을 거두었지만, 많은 기업이 서버 인프라에 대한 어느 정도의 통제력을 원한다. 이런 백엔드를 담당하는 엔지니어도 더 나은 경험을 원할 수 있다. 레드몽크(RedMonk) 애널리스트 제임스 가버너는 “개발자가 이런 작업을 더 쉽게 할 수 있도록 서비스 업체가 지원에 나서는 것은 자연스러운 현상이며, 이 부분이 인프라와 소프트웨어 개발이 만나는 지점이다. 결국 헬름 차트, 연산자 또는 YAML을 수동으로 다룰 필요 없이 생산성을 높일...

개발자경험 백엔드 오픈소스 YAML 코드형인프라. IaC 클라우드네이티브 데브옵스

2022.05.11

코드형 인프라와 데브옵스, 내부 플랫폼의 인기가 높아지면서 백엔드 개발자가 탄력적이면서 성능과 확장성이 우수한 서버 측 애플리케이션과 서비스를 구축하기에 훨씬 더 좋은 환경이 됐다. 그러나 너무 많은 부담을 짊어지고 있기도 하다. 현대 애플리케이션의 복잡함으로 인해 백엔드 개발자는 리눅스의 기본부터 스크립트 언어, 로깅, 모니터링, 클라우드 기반 네트워킹과 서비스 메시, 관찰 가능성, 쿠버네티스 클러스터, 그리고 공포의 YAML 파일에 이르기까지 갈수록 많은 툴과 기술, 기법을 마스터해야 한다.   백엔드 개발자에게는 숨을 쉴 공간, 명확히 말하자면 더 나은 개발 경험이 필요하다. 다행히 툴 제조 업체들이 앞다퉈 그런 경험을 제공하고 있다. 코드형 인프라의 장벽을 낮추는 것부터 쿠버네티스 워크플로우와 분산 앱 배포 과정을 원활하게 하고 필요에 따라 클라우드에 개발자 작업 공간을 마련하는 데 이르기까지, 새롭게 쏟아지는 여러 프로젝트는 서버 측에서 고난을 겪고 있는 개발자가 더 편하게 작업을 수행하는 데 도움이 될 것을 약속한다.   "백엔드 엔지니어도 감정이 있다" 오늘날의 클라우드 네이티브 세계에서 모든 유형의 개발자는 일반적으로 더 직관적이고 사용하기 쾌적한 툴에 자연스럽게 이끌린다. 간편함이나 사용 편의성과 거리가 먼 영역에서 일하는 경우라 해도 마찬가지다. 버셀(Vercel)이나 네트리파이(Netlify)와 같은 업체는 프론트엔드 개발자 경험에 초점을 두고 백엔드를 추상화하는 방식으로 큰 성공을 거두었지만, 많은 기업이 서버 인프라에 대한 어느 정도의 통제력을 원한다. 이런 백엔드를 담당하는 엔지니어도 더 나은 경험을 원할 수 있다. 레드몽크(RedMonk) 애널리스트 제임스 가버너는 “개발자가 이런 작업을 더 쉽게 할 수 있도록 서비스 업체가 지원에 나서는 것은 자연스러운 현상이며, 이 부분이 인프라와 소프트웨어 개발이 만나는 지점이다. 결국 헬름 차트, 연산자 또는 YAML을 수동으로 다룰 필요 없이 생산성을 높일...

2022.05.11

"쿠버네티스, 왜 이리 배우기 어려운가?" 공동 창업자가 내놓은 답변 보니

쿠버네티스 공동 창업자는 컨테이너 오케스트레이션 소프트웨어가 리눅스 커널처럼 보편화되고 구성도 용이해져, 도입을 넘어선 그 다음 단계로 넘어가기를 바라고 있다.  쿠버네티스의 공동 창업자인 조 베다는 컨테이너 오케스트레이션 툴이 학습하기 까다롭다고 인정하면서, 쿠버네티스가 도입을 넘어 다음 단계로 나아가려면, 커뮤니티가 쿠버네티스 기술을 리눅스 커널처럼 보편화하는 데 초점을 맞춰야 한다고 전했다.   베다는 브라이트토크에서 진행된 ‘무엇이든 물어보세요’ 세션에서 "이제 쿠버네티스는 다양한 생태계의 근간이자 애플리케이션 배포 및 관리를 위한 방식으로 여겨지고 있다"라고 말했다. 쿠버네티스 초창기에는 생각하지 못했던 바다. 베다는 “이렇게 될 것이라고는 예상하지 못했다”라고 말했다.   쿠버네티스가 엔터프라이즈 개발자들이 사용하는 핵심 기술이 된 만큼 베다는 두 가지 목표를 갖고 있다. 하나는 쿠버네티스를 안정적이면서 유용한 플랫폼으로 만들어, 리눅스 커널처럼 운영체제의 기본 구성요소로 자리잡을 수 있도록 하는 것이다.  다른 하나는 쿠버네티스에 흥미롭고 새로운 기능을 구축하는 것이다. 베다는 "사람들이 (쿠버네티스에) 놀라운 기능들을 구축하고 있다. 이를 바탕으로 흥미로운 작업을 해볼 수 있을 것이다. 쿠버네티스를 활용한 여러 프로젝트들이 이미 있다"라고 말했다.     베다는 2014년에 쿠버네티스를 위한 첫 번째 커밋을 작성했다. 그는 구글에서 10년간 근무한 후 현재 VM웨어의 수석 엔지니어로 일하고 있다. 베다가 사람들과 대화를 나누는 가운데 쿠버네티스에 대해 받은 핵심 질문 두 가지에 대한 답을 아래와 같이 정리했다.  왜 이스티오는 쿠버네티스와 별도로 존재하는가? 베다가 아주 흥미로워 했던 질문 중 하나는 다음과 같다. 오픈소스 서비스 메시인 이스티오(Istio)는 보통 쿠버네티스와 한쌍을 이루고, 구글 엔지니어들이 주로 개발했는데 왜 쿠버네티스와 좀...

쿠버네티스 조 베다 오케스트레이션 리눅스 커널 이스티오 오픈소스 구글 링커드 서비스메시 YAML 베어메탈 코드형 인프라

2021.02.03

쿠버네티스 공동 창업자는 컨테이너 오케스트레이션 소프트웨어가 리눅스 커널처럼 보편화되고 구성도 용이해져, 도입을 넘어선 그 다음 단계로 넘어가기를 바라고 있다.  쿠버네티스의 공동 창업자인 조 베다는 컨테이너 오케스트레이션 툴이 학습하기 까다롭다고 인정하면서, 쿠버네티스가 도입을 넘어 다음 단계로 나아가려면, 커뮤니티가 쿠버네티스 기술을 리눅스 커널처럼 보편화하는 데 초점을 맞춰야 한다고 전했다.   베다는 브라이트토크에서 진행된 ‘무엇이든 물어보세요’ 세션에서 "이제 쿠버네티스는 다양한 생태계의 근간이자 애플리케이션 배포 및 관리를 위한 방식으로 여겨지고 있다"라고 말했다. 쿠버네티스 초창기에는 생각하지 못했던 바다. 베다는 “이렇게 될 것이라고는 예상하지 못했다”라고 말했다.   쿠버네티스가 엔터프라이즈 개발자들이 사용하는 핵심 기술이 된 만큼 베다는 두 가지 목표를 갖고 있다. 하나는 쿠버네티스를 안정적이면서 유용한 플랫폼으로 만들어, 리눅스 커널처럼 운영체제의 기본 구성요소로 자리잡을 수 있도록 하는 것이다.  다른 하나는 쿠버네티스에 흥미롭고 새로운 기능을 구축하는 것이다. 베다는 "사람들이 (쿠버네티스에) 놀라운 기능들을 구축하고 있다. 이를 바탕으로 흥미로운 작업을 해볼 수 있을 것이다. 쿠버네티스를 활용한 여러 프로젝트들이 이미 있다"라고 말했다.     베다는 2014년에 쿠버네티스를 위한 첫 번째 커밋을 작성했다. 그는 구글에서 10년간 근무한 후 현재 VM웨어의 수석 엔지니어로 일하고 있다. 베다가 사람들과 대화를 나누는 가운데 쿠버네티스에 대해 받은 핵심 질문 두 가지에 대한 답을 아래와 같이 정리했다.  왜 이스티오는 쿠버네티스와 별도로 존재하는가? 베다가 아주 흥미로워 했던 질문 중 하나는 다음과 같다. 오픈소스 서비스 메시인 이스티오(Istio)는 보통 쿠버네티스와 한쌍을 이루고, 구글 엔지니어들이 주로 개발했는데 왜 쿠버네티스와 좀...

2021.02.03

도커와 MS의 최신 오픈소스 표준 'CNAB'를 아십니까?

도커와 마이크로소프트가 분산 컴퓨팅을 크게 단순화하는 ‘보편적 표준’을 위해, 그리고 아직 정체불명인 3~4곳의 상대방과 클라우드 네이티브 재단을 설립하기 위해 서로 힘을 합쳤다.    도커의 최고 제품 임원인 스캇 존스턴은 ‘클라우드 네이티브 애플리케이션 번들('Cloud Native Application Bundle)’, 즉 CNAB가 개발자 커뮤니티에 지대한 영향을 줄 것으로 믿는다고 말했다. 도커 컨테이너가 처음에 그랬던 것처럼 말이다.  CNAB는 마이크로소프트와 제휴하여 개발되었고, 다수의 서비스를 패키지로 묶어 실행의 복잡성을 단순화하는 것을 목표로 한다. 쿠버네티스 YAML, 헬름 차트(Helm charts), 도커 컴포즈 파일(Docker Compose files), 클라우드포메이션(CloudFormation), 테라폼(Terraform), ARM 템플릿 등을 단일 패키지로 묶어 처리할 수 있고, 실행 환경 측면에서 클라우드 종류를 구분하지 않는다고 한다.  존스턴은 바르셀로나에서 열린 도커콘 유럽 2018 중 기자들과 만난 자리에서, 도커는 고객 및 개발자 커뮤니티의 피드백을 바탕으로, 상당 기간 이 문제에 대처하기 위해 연구해왔다고 밝혔다. 그러던 중 약 1년 전 마이크로소프트가 복잡성의 처리를 둘러싼 비슷한 문제를 놓고 도커와 접촉하였다.  두 회사는 상이한 고객 기반, 그리고 심지어 인-하우스 애저 서비스 팀조차 근접한 난제를 직면하고 있어서 규격에 관해 공동으로 대처하는 것이 합리적임을 깨달았다.  존스턴은 “시간이 가면서 이의 도입이 더욱 늘어날 것이다”면서 “도커 컨테이너뿐 아니라, 분산 애플리케이션의 보편적 표준이 될 것이다. 그리고 정말 중요한 것은, 이는 도커의 전유물도, 마이크로소프트의 전유물도 아니라는 점이다. 컴포즈 파일을 입력으로 취할 수 있고, 헬름 차트를 입력으로 취할 수...

클라우드 CNAB 마이크로서비스 도커콘 쿠버네티스 번들 네이티브 복잡성 표준 포레스터 애플리케이션 마이크로소프트 오픈소스 YAML

2018.12.07

도커와 마이크로소프트가 분산 컴퓨팅을 크게 단순화하는 ‘보편적 표준’을 위해, 그리고 아직 정체불명인 3~4곳의 상대방과 클라우드 네이티브 재단을 설립하기 위해 서로 힘을 합쳤다.    도커의 최고 제품 임원인 스캇 존스턴은 ‘클라우드 네이티브 애플리케이션 번들('Cloud Native Application Bundle)’, 즉 CNAB가 개발자 커뮤니티에 지대한 영향을 줄 것으로 믿는다고 말했다. 도커 컨테이너가 처음에 그랬던 것처럼 말이다.  CNAB는 마이크로소프트와 제휴하여 개발되었고, 다수의 서비스를 패키지로 묶어 실행의 복잡성을 단순화하는 것을 목표로 한다. 쿠버네티스 YAML, 헬름 차트(Helm charts), 도커 컴포즈 파일(Docker Compose files), 클라우드포메이션(CloudFormation), 테라폼(Terraform), ARM 템플릿 등을 단일 패키지로 묶어 처리할 수 있고, 실행 환경 측면에서 클라우드 종류를 구분하지 않는다고 한다.  존스턴은 바르셀로나에서 열린 도커콘 유럽 2018 중 기자들과 만난 자리에서, 도커는 고객 및 개발자 커뮤니티의 피드백을 바탕으로, 상당 기간 이 문제에 대처하기 위해 연구해왔다고 밝혔다. 그러던 중 약 1년 전 마이크로소프트가 복잡성의 처리를 둘러싼 비슷한 문제를 놓고 도커와 접촉하였다.  두 회사는 상이한 고객 기반, 그리고 심지어 인-하우스 애저 서비스 팀조차 근접한 난제를 직면하고 있어서 규격에 관해 공동으로 대처하는 것이 합리적임을 깨달았다.  존스턴은 “시간이 가면서 이의 도입이 더욱 늘어날 것이다”면서 “도커 컨테이너뿐 아니라, 분산 애플리케이션의 보편적 표준이 될 것이다. 그리고 정말 중요한 것은, 이는 도커의 전유물도, 마이크로소프트의 전유물도 아니라는 점이다. 컴포즈 파일을 입력으로 취할 수 있고, 헬름 차트를 입력으로 취할 수...

2018.12.07

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.4.0.13