GCP Cloud Engineer - 61

2024-04-18

컨테이너의 정의 및 특징:
- ㅁ 컨테이너는 애플리케이션 코드를 실행하기 위한 격리된 사용자 공간입니다.
- ㅁ 경량화되어 있고, 전체 운영체제를 포함(X)하지 않아 효율적으로 자원을 사용합니다.
- ㅁ 컨테이너는 빠르게 생성 및 종료될 수 있습니다.
컨테이너의 이점:
- ㅁ 애플리케이션과 그 종속성만을 가상화하여 의존성 문제를 해결합니다.
- ㅁ 개발자는 시스템의 나머지 부분에 대해 걱정할 필요 없이 애플리케이션 중심의 개발을 할 수 있습니다.
- ㅁ 어디에서나 동일하게 실행될 수 있는 휴대성을 제공합니다.

가상화의 역사:
- ㅁ 과거에는 애플리케이션을 물리적 컴퓨터에 직접 배포했습니다.
- ㅁ 가상화는 여러 가상 서버를 같은 물리적 컴퓨터에서 실행할 수 있게 했습니다.
- ㅁ 하이퍼바이저가 운영체제와 하드웨어 사이의 종속성을 해결합니다.
가상화의 문제점:
- ㅁ 의존성 공유로 인한 애플리케이션 간 간섭이 발생할 수 있습니다.
- ㅁ 운영체제가 포함되어 있어 무거워서 시작 시간이 길어집니다.
- ㅁ 각 애플리케이션을 위한 별도의 VM을 운영하는 것은 자원을 낭비할 수 있습니다.

개발 및 배포:
- ㅁ 컨테이너는 마이크로서비스 설계 패턴을 사용하여 애플리케이션을 구축하는 데 이상적입니다.
- ㅁ 변경사항을 기반으로 컨테이너를 신속하게 배포할 수 있습니다.
- ㅁ 컨테이너는 개발 과정을 가속화하고 애플리케이션의 확장성을 높입니다.

클라우드 빌드와의 통합:
- ㅁ Google의 Cloud Build와 통합하여 애플리케이션 이미지를 구축하고 관리할 수 있습니다.
- ㅁ 컨테이너는 클라우드 환경에서의 애플리케이션 배포를 간소화합니다.

컨테이너 이미지:
- ㅁ 컨테이너 이미지는 애플리케이션과 그 종속성을 포함합니다.
- ㅁ 이미지는 도커와 같은 도구를 사용하여 빌드됩니다.
- ㅁ 컨테이너는 이미지의 실행 인스턴스입니다.
컨테이너의 기술적 구성:
- ㅁ 리눅스 프로세스, 네임스페이스, cgroups, 그리고 유니언 파일 시스템을 사용하여 컨테이너의 격리와 자원 제어를 달성합니다.
- ㅁ 각 컨테이너는 격리된 사용자 공간에서 실행됩니다.

도커파일:
- ㅁ 컨테이너 이미지를 빌드하기 위한 도커파일은 레이어를 지시합니다.
- ㅁ 각 명령은 이미지 내의 새로운 레이어를 생성합니다.
- ㅁ 이미지 레이어는 읽기 전용이며, 컨테이너 실행 시 쓰기 가능한 최상위 레이어가 추가됩니다.
멀티스테이지 빌드:
- ㅁ 현대의 Best Practice 는 빌드와 실행을 분리하는 멀티스테이지 빌드 프로세스를 사용합니다.
- ㅁ 빌드 도구는 배포 컨테이너에서 제거되어 추가 공격 벡터를 제거합니다.

구글 클라우드 빌드:
- ㅁ 소스 코드로부터 컨테이너 이미지를 자동으로 빌드하고 관리합니다.
- ㅁ IAM과 통합하여 액세스를 제어하고, 이미지 보안 스캔을 제공합니다.
- ㅁ 다양한 실행 환경으로 이미지를 배포할 수 있습니다.
아티팩트 레지스트리:
- ㅁ 컨테이너 이미지와 언어, OS 패키지를 저장할 수 있는 중앙 집중식 장소입니다.
- ㅁ 보안과 액세스 제어를 강화할 수 있는 구글 클라우드 서비스와 통합됩니다.

하이퍼바이저는 가상화에서 중요한 역할을 하는 컴퓨터 소프트웨어, 하드웨어 또는 펌웨어입니다.

하이퍼바이저는 물리적인 호스트 시스템에서 여러 가상 머신(VM)이 동시에 실행되도록 하는 역할을 합니다.

이를 통해 각 가상 머신은 독립적인 시스템처럼 작동하며, 자체 운영체제를 가질 수 있습니다.

하이퍼바이저는 두 가지 유형이 있습니다:

타입 1(Native/Bare-Metal) 하이퍼바이저:

하이퍼바이저가 직접 하드웨어 위에 설치되며, 모든 가상 머신이 하이퍼바이저 위에 직접 실행됩니다.

타입 2(Hosted) 하이퍼바이저:

하이퍼바이저가 일반적인 소프트웨어처럼 호스트 운영체제 위에 설치되며, 가상 머신은 이 하이퍼바이저 위에서 실행됩니다.

하이퍼바이저는 가상 머신의 리소스를 관리하고, 가상 머신 간에 하드웨어 리소스를 공유하도록 조정하는 역할을 합니다.

"의존성 공유로 인한 애플리케이션 간 간섭"이 발생하는 이유는, 여러 애플리케이션들이 동일한 라이브러리나 시스템 리소스를 공유하면서 발생하는 문제들 때문입니다.

예를 들어, 두 애플리케이션이 같은 라이브러리를 사용하지만, 서로 다른 버전을 필요로 하는 경우, 한 애플리케이션의 라이브러리 업데이트가 다른 애플리케이션에 영향을 줄 수 있습니다.

이는 "DLL 지옥(DLL Hell)"이라고도 불리는 문제입니다.

또한, 여러 애플리케이션들이 동일한 시스템 리소스(예: 메모리, CPU, I/O 등)를 공유하는 경우, 한 애플리케이션의 과도한 리소스 사용이 다른 애플리케이션의 성능에 영향을 줄 수 있습니다.

이러한 문제들은 컨테이너화를 통해 해결할 수 있습니다.

컨테이너는 각 애플리케이션과 그 종속성들을 격리된 환경에 패키징함으로써, 애플리케이션 간의 의존성 문제와 리소스 간섭 문제를 방지합니다.

"추가 공격 벡터"는 보안 측면에서 새로운 취약점이나 위협이 될 수 있는 경로를 의미합니다.

공격 벡터는 공격자가 시스템을 공격하는 데 사용하는 방법이나 경로를 나타냅니다.

이는 이메일, 웹사이트, 클라우드 저장소, 네트워크 인터페이스 등 다양한 형태가 될 수 있습니다.

"추가 공격 벡터"는 새로운 기능, 설정, 코드, 의존성 등이 시스템에 추가될 때 발생할 수 있습니다.

이러한 추가 요소들은 공격자에게 새로운 공격 경로를 제공할 수 있으므로, 새로운 요소를 추가할 때는 항상 보안을 고려해야 합니다.

GCP Cloud ...