새로운 버전의 컨테이너를 배포할때도 무중단배포가 가능합니다.
OpenShift에는 S2I Source To Image라는 개념이 있는데요. 개발자가 소스코드만 SCM(git)에 업로드를 한다면 OpenShift의 BuildConfig라는 Object를 이용하여 컨테이너 이미지로 OpenShift가 만들어 주고 해당 이미지를 기반으로 배포도 자동으로 이루어지도록 할 수 있습니다.
컨테이너에 실질적으로 변경을 하더라도 컨테이너는 휘발성을 가지고 있기 때문에 저장할 수 없습니다. 그렇기 때문에 Read Only 특성인데요. 만약 컨테이너에 변화 혹은 수정이 필요하다고 하면 컨테이너의 근본이 되는 컨테이너 이미지를 새로 만들어야합니다.
도커는 컨테이너를 손쉽게 사용할 수 있도록 지원하는 '도구'입니다
업그레이드 된 Base Image(Python, Node.js)를 이용하여 새로운 container Image(실제 서비스를할)를 생성해야합니다.
OpenShift에는 Image stream이라는 Object가 존재하는데 이 Object를 이용하여 OpenShift에서 사용된 이미지 이력, 버전 관리 할 수 있습니다.
오토스케일링은 수평확장입니다, 이때 컨테이너 개수만 늘어나고 Service라는 고정적인 Object를 이용하여 부하분산이 이루어지기 때문에 복잡하지 않습니다
상황에 맞게도 적용 가능합니다.
OpenShift의 Source to Image, MachineConfig, Template 등등의 기능으로 간소화 할 수 있을것으로 생각됩니다. 어플리케이션의 로드밸런싱은 Service라는 Object를 이용하여 가능합니다.
모든 컨테이너가 오토힐링 대상입니다. OpenShift가 컨테이너에 헬스체크를 하는데 헬스체크에 실패할 경우 기존의 컨테이너를 폐기시키고 새로 기동시킵니다. 말씀하신대로 향후 장애발생에 따라 오토힐링정책을 커스터마이징할 수도 있습니다.
서드파티인 OPENMARU APM을 이용하여 어플리케이션 레벨의 모니터링이 가능합니다.
Container Image를 기반으로 컨테이너가 구동되게 되는데 오토스케일링시 기존에 사용했던 Container Image를 기반으로 새로운 컨테이너를 동작시키는 개념입니다.
오토스케일링 정책에 MAX 컨테이너 개수를 지정할 수 있습니다.
휘발되지 않아야하는 데이터는 Persistent Volume을 이용하여 데이터를 남길 수도 있고 로그 데이터라면 Elastic Search Fluentd Kibana 스택을 이용하여 저장할 수도 있습니다.
어플리케이션이 동작하는데 필요한 환경 (OS, 환경변수, WAS 등등)을 포함시켜서 Container Image를 만들 경우 인프라 레벨에서의 환경차이를 최소화 할 수 있습니다.
롤링 업데이트 가능합니다.
메트릭 정보를 수집하는 grafana, prometheus와 Elasticsearch, Fluent, Kibana 스택으로 컨테이너의 Log를 수집할수 있습니다. 또한 서드파티 제품인 OPENMARU APM을 이용하여 어플리케이션, OpenShift Node 모니터링도 가능합니다.
컨테이너 환경에서는 replica를 이용하여 이중화,삼중화 N중화가 마우스 클릭 몇번만으로도 가능합니다.
컨테이너에 할당된 리소스를 기준으로 CPU, Memory의 몇%사용 했는지에 따라 확장되고 축소됩니다.
네 가능합니다
