| Info |
|---|
2018 년 4 월 21 일 |
| Info | |
|---|---|
|
Containerizing interpreted languages
...
참고 : 더 많은 공간을 절약하고 사용하지 않는 종속성을 제거하려면 Google 의 distroless 프로젝트 를 살펴 보는 것이 좋습니다 . Java 사용자는 Jib을 확인할 수도 있습니다 . 그러나 Alpine은 표준 디버깅 도구를 사용하고 종속성을 설치하는 것이 훨씬 쉽기 때문에 기본 이미지로 여전히 좋은 선택입니다 (공격을위한 더 많은 공간과 약간 더 높은 표면적 비용으로).
컨테이너를 만들고 보관할 위치
이미지를 빌드하고 저장하려면 Google Container Builder 와 Google Container Registry를 함께 사용하는 것이 좋습니다 . Container Builder는 매우 빠르며 이미지를 Container Registry에 자동으로 푸시합니다. 대부분의 개발자는 무료 등급에서 모든 작업을 쉽게 수행해야하며 Container Registry는 원시 Google Cloud Storage 와 동일한 가격입니다 (저렴합니다!).
...
또한 Container Registry는 즉시 취약성 스캔 도구와 IAM 지원을 제공합니다. 이러한 도구를 사용하면 컨테이너를보다 쉽게 보호하고 잠글 수 있습니다.
더 작은 컨테이너의 성능 평가
사람들은 소형 컨테이너의 가장 큰 장점은 구축 시간과 풀링 시간 모두의 단축이라고 주장합니다. onbuild로 만든 컨테이너와 다단계 프로세스에서 Alpine으로 만든 컨테이너를 사용하여이를 테스트 해 보겠습니다!
| Info |
|---|
요약 : 강력한 컴퓨터 나 Container Builder에 대해서는 큰 차이가 없지만, 더 작은 컴퓨터와 공유 시스템 (많은 CI / CD 시스템처럼)에 대해서는 큰 차이가 있습니다. 작은 이미지는 절대적인 성능 측면에서 항상 더 좋습니다. |
대형 머신에서 이미지 빌드
첫 번째 테스트에서는 꽤 튼튼한 노트북을 사용하여 빌드 할 것입니다. 사무실 WiFi를 사용하고 있으므로 다운로드 속도가 매우 빠릅니다!
...
각 빌드에 대해 캐시에서 모든 Docker 이미지를 제거합니다.
| Info |
|---|
|
...
|
...
다음 테스트는 컨테이너를 원격 레지스트리로 푸시하는 것입니다. 이 테스트에서는 Container Registry를 사용하여 이미지를 저장했습니다.
| Info |
|---|
|
...
|
...
마지막으로 레지스트리에서 로컬 컴퓨터로 이미지를 가져 오는 데 걸리는 시간을 테스트하고 싶습니다.
| Info |
|---|
Pull:
|
20 초에 두 개의 서로 다른 컨테이너 이미지를 사용하는 것의 가장 큰 차이입니다. 특히 이미지를 자주 가져 오는 경우 더 작은 이미지 사용의 이점을 볼 수 있습니다.
Container Builder를 사용하여 클라우드에서 컨테이너를 빌드 할 수도 있습니다.이 경우 Container Registry에 컨테이너를 자동으로 저장하는 추가 이점이 있습니다.
| Info |
|---|
Build + Push :
|
다시 말하지만, 더 작은 이미지를 사용하면 약간의 이점이 있지만 예상했던 것만 큼 극적이지는 않습니다.
소형 기계에 이미지 구축
그렇다면 더 작은 용기를 사용하는 것이 유리할까요? 빠른 인터넷 연결 및 / 또는 Container Builder를 갖춘 강력한 노트북이 있다면 그렇지 않습니다. 그러나 덜 강력한 기계를 사용하면 이야기가 바뀝니다. 이를 시뮬레이션하기 위해 겸손한 Google Compute Engine f1-micro VM을 사용하여 이러한 이미지를 빌드하고, 푸시하고, 가져 왔는데 결과는 놀랍습니다!
| Info |
|---|
Pull:
|
| Info |
|---|
Build:
|
| Info |
|---|
Push:
|
이 경우 더 작은 컨테이너를 사용하면 정말 도움이됩니다!
Pulling on Kubernetes
컨테이너를 만들고 밀어내는 데 걸리는 시간은 신경 쓰지 않을 수도 있지만 컨테이너를 당기는 데 걸리는 시간은 정말 신경 써야합니다. Kubernetes의 경우 이는 프로덕션 클러스터에서 가장 중요한 지표 일 것입니다.
...
여러 배포에서 여러 컨테이너의 풀 성능이 여기에 실제로 추가 될 수 있으며 작은 컨테이너를 사용하면 잠재적으로 배포 시간에서 몇 분을 단축 할 수 있음을 알 수 있습니다.
보안 및 취약성
성능 외에도 더 작은 컨테이너를 사용하면 상당한 보안 이점이 있습니다. 작은 컨테이너는 일반적으로 큰 기본 이미지를 사용하는 컨테이너에 비해 공격 표면이 더 작습니다.
...
대부분의 문제는 우리 앱과 관련이 없으며 오히려 우리가 사용하지 않는 프로그램과 관련이 있음을 알 수 있습니다! 다단계 이미지는 훨씬 더 작은 기본 이미지를 사용하기 때문에 손상 될 수있는 항목이 더 적습니다.
결론
소형 컨테이너 사용의 성능 및 보안 이점은 그 자체로 입증됩니다. 작은 기본 이미지와 "빌더 패턴"을 사용하면 작은 이미지를 더 쉽게 빌드 할 수 있으며 개별 스택 및 프로그래밍 언어를위한 다른 많은 기술도 컨테이너 크기를 최소화 할 수 있습니다. 무엇을 하든지 컨테이너를 작게 유지하려는 노력이 그만한 가치가 있음을 확신 할 수 있습니다!