https://docs.microsoft.com/en-us/azure/container-apps/compare-options

 

Comparing Container Apps with other Azure container options

Understand when to use Azure Container Apps and how it compares to other container options including Azure Container Instances, Azure App Service, Azure Functions, and Azure Kubernetes Service.

docs.microsoft.com

 

총 7가지의 Container 서비스가 존재한다.

 

* Azure Container Apps

서버리스 마이크로 서비스 용도. 쿠버네티스 위에서 돌아가지만, 쿠버네티스를 직접 접근할 수 없다.

많은 팀들이 컨테이너 마이크로 서비스를 Azure Container Apps으로 시작한다고 하네. (진짠진 모름ㅋ)

 

* Azure App Service

코드 혹은 컨테이너 이미지로 배포.

Web application에 최적화 되어있음. 사실상 Web Hosting을 위한거라고 봐도 됨.

Azure Container Apps와 Azure Functions와 같이 쓰인다고 함.

Web app을 배포할 때 App Service가 이상적 옵션이다.

 

* Azure Container Instances

Azure Container Instances (ACI) provides a single pod of Hyper-V isolated containers on demand. It can be thought of as a lower-level "building block" option compared to Container Apps. Concepts like scale, load balancing, and certificates are not provided with ACI containers. For example, to scale to five container instances, you create five distinct container instances. Azure Container Apps provide many application-specific concepts on top of containers, including certificates, revisions, scale, and environments. Users often interact with Azure Container Instances through other services. For example, Azure Kubernetes Service can layer orchestration and scale on top of ACI through virtual nodes. If you need a less "opinionated" building block that doesn't align with the scenarios Azure Container Apps is optimizing for, Azure Container Instances is an ideal option.

음... 이건 좀 번역이 까다로운데, 단일한 pod으로 켜지는거고, 스케일링, 로드밸런싱, 인증 같은건 지원 안된다네.

구체적인 시나리오에 맞춰져있지 않은, 그야말로 블럭을 하나씩 쌓는 그런 기능을 원하면 ACI를 쓰래.

 

* Azure Kubernetes Service

요거는 당근 알구.

 

* Azure Functions

Functions as a Service래. SaaS도 아니고 이건 뭐지 ㅋㅋ

Event driven application에 최적화 되어있다고 하고.

많은 특징을 스케일링과 integration with events와 공유한대.

Event가 trigger 해서 어떤 logic이 실행되게 할 수 있다.

먼가 basic container image에서도 돌아가서 좀 가볍고, 환경 변수 입력해서 하드코딩 안하고 코드 재사용 할 수 있게 한다 머 이런 뜻 같음.

 

* Azure Spring Cloud

스프링 부트 마이크로서비스 애플리케이션을 코드 수정 없이 Azure에 배포할 수 있대.

서비스가 인프라를 알아서 관리해가지고 개발자들은 코드에만 집중할 수 있다네.

Azure Spring Cloud provides lifecycle management using comprehensive monitoring and diagnostics, configuration management, service discovery, CI/CD integration, blue-green deployments, and more

머 모니터링이랑 진단, 구성 관리, 서비스 디스커버리, CI/CD, 블루-그린 배포까지 다 지원한대.

ㄴ Service Discovery란?

 

MSA와 같은 분산 환경은 서비스 간의 원격 호출로 구성이 된다. 원격 서비스 호출은 IP 주소와 포트를 이용하는 방식이 되는다.

클라우드 환경이 되면서 서비스가 오토 스케일링등에 의해서 동적으로 생성되거나 컨테이너 기반의 배포로 인해서, 서비스의 IP가 동적으로 변경되는 일이 잦아졌다.

그래서 서비스 클라이언트가 서비스를 호출할때 서비스의 위치 (즉 IP주소와 포트)를 알아낼 수 있는 기능이 필요한데, 이것을 바로 서비스 디스커버리 (Service discovery)라고 한다.
출처: https://bcho.tistory.com/1252 [조대협의 블로그]

 

* Azure Red Hat OpenShift

OpenShift에서 돌아가는 쿠버네티스 서비스래. 

With Azure Red Hat OpenShift, teams can choose their own registry, networking, storage, and CI/CD solutions, or use the built-in solutions for automated source code management, container and application builds, deployments, scaling, health management, and more from OpenShift. 

이런 여러 가지 기능들 지원한다고 하고, "이미 OpenShift를 쓰고 있으면 사용하래."

  • 네이버 블러그 공유하기
  • 네이버 밴드에 공유하기
  • 페이스북 공유하기
  • 카카오스토리 공유하기