Docker 명령어가 Client의 역할을 한다.

Docker Engine이 띄어져 있는 곳을 Docker Host 이다.  

Docker HOST에는 images랑 Containers가 있다.

images를 어떻게 관리를 하냐면, image는 직접 bulid하는 방법, 혹은 pull 명령어를 통해 remote해서 가져오는 방법이 있다.

이미지를 가져올 때 쓰는 것을 registry(이미지 저장소) 라고 한다.

이미지저장소에서 다른 사람들이 공유해준 이미지를 가져와서 로컬 도커 호스트에 저장할 수 있고,

이미지 저장소로 부터 실행을 시키면 Container가 된다.

위의 그림 처럼, 이미지와 컨테이너는 1:N 관계 이다.

위의 그림은, Docker가 Image를 만들 때 사용하는 file이 Docker File이 있다. 이걸 준비해서 BUILD를 수행하면,

Docker Image가 만들어 진다. Docker Image를 Docker Run명령어를 통해서  실행시키면 Docker Container가 된다.

이런 기본적인 작업 Cycle이 있다. 

위의 그림처럼 Repository Name/Image Name:Image Tag를 통해 이름을 구성한다.

Image Tag를 생략하면, 최신 리비전을 가리킨다.

저장소 이름이 생략되면 도커 허브로 인식 된다. 

< Docker 이미지 저장소 >

도커 이미지 저장소는 Docker image를 관리하고 공유하기 위한 서버 어플리케이션 이다.

Public과 private으로 나뉜다.  Public은 Dockerhub와 Quay가 있다.

비공개형 이미지 저장소는 기업에서 이미지를 관리하고 공유하는 목적이다. 주로 AWS ECR을 통해 팀 내에 비공개 형태로 운영하다. Docker Registry도 가능하다.

< 구성 요소 >

Docker Registry를 통해서 Ubuntu나 cassandra, Oracle에서 사전에 준비된 이미지를 통해 Pull,run 명령어를 통해 HOST에 이미지 저장 되고, Container를 실행 시킴으로써 Docker Demon이 Container를 관리할 수 있게 된다.

출처: FastCampus Kubernetes와 Docker로 한 번에 끝내는 컨테이너 기반 MSA

< 컨테이너 기술의 발전 >

기업들이 어떻게 서비스를 '효율적'으로 운영할 것 인가?를 어떻게 풀어왔는지 과거로 돌아가볼 필요가 있다.

가상화 기술이 발전하기 전

아래의 그림과 같이 Hardware에 OS가 설치, 그 위에 App에 필요한 Lib&Framework를 운영체제에 설치하고 실행을 할 수 있게 하였다.

< 발생하는 문제 >

추후에 다양한 서비스들이 실행이 되어야 하는 needs가 생기가 되고, 어떻게 하면 비용 효율성과 컴퓨팅 자원을 최대한 잘 쓸 수 있을까?

라는 고민을 하게 된다.

예를 들어 하나의 컴퓨터에 App1, App2, App3이 있을 수 있는데

App1이 필요로 하는 것이 L1, L2가 있을 수 있고 App2 App1 App3가 있을 수 있다.

App3는 L4가 필요로 한다면, App은 L1의 version 1을 의존성으로 가질 수 있고

App2는 L1의 version2를 의존성으로 가질 수 있다. 근데 보통 운영체제들이 공유 라이브러리를 설치하는 환경에서는 동일한 공유 라이브러리에서는 하나의 버전만 설치를 하게끔 허용하는 것이 대부분인데, 이러한 경우 보통 정적으로 컴파일된 L1 라이브러리를 app1과 배포해서 해결하는 방법도 있다.

이런 식으로 각각 애플리케이션이 공유하는 자원 충돌이 생기게 된다.

이러한 문제를 해결하기 위해 기업들은 고민하게 되고 어떻게 하면 app1,2,3을 격리를 시켜서 문제가 발생하지 않도록 하면서 컴퓨팅 자원을 효율적으로 쓸 수 있을까?

고민을 하게 된다. 그 고민을 통해서 나온 게 가상화 기술이라고 할 수 있다.

위의 그림은 가상머신을 이용한 가상화 방법인데, 하드웨어 위에 운영체제 위에 Hypervisor가 올라가게 되는데,

Hardware를 대상으로 하다 보니, 성능 효율성이 떨어지고 자원의 Overhead가 발생한다.

-> 이러한 문제들을 풀기 위해 어떠한 기술을 사용해야 문제점들을 해결할까? 해서 탄생한 기술이 아래의 그림이다.

하드웨어 위에 운영체제가 설치되고, 그 위에는 Docker 엔진이 위치하게 된다. 이러한 구조에서, 각각의 Docker 컨테이너는 호스트 운영체제에서 볼 때 일종의 프로세스로 처리된다. 이는 호스트 운영체제에서 직접 실행되는 프로세스와 본질적으로 큰 차이가 없지만, 몇 가지 중요한 차이점을 통해 격리 기술을 제공한다.

Docker는 chroot, 네임스페이스 등의 기술을 활용하여 프로세스 ID 격리, 네트워크 격리 등을 제공한다. 따라서 Docker 컨테이너는 호스트 운영체제에서 실행되는 프로세스이긴 하지만, 호스트 운영체제의 커널을 공유하면서도 다른 프로세스로부터 격리된 환경을 제공한. 이러한 점이 Docker 컨테이너를 특별하게 만든다.

Docker 컨테이너의 이런 특성 덕분에, 호스트 운영체제에서 직접 실행되는 프로세스에 비해 자원 오버헤드가 매우 적다. 또한, 각 컨테이너가 독립적인 환경을 가지므로 의존성 충돌 문제도 최소화된다. 이런 특징들이 Docker를 매우 효율적인 도구로 만들어 주었다.

< 쿠버네티스는 무엇인가? >

Container Orchestration System

Contatiner Engine 같은 경우, 하나의 서버 위에 Container를 어떻게 관리할 수 있을까 하는 "관리 소프트웨어"라고 보면 돼,  "Container Orchestration System은 여러 서버로 구성된 클러스터 환경에서 컨테이너들을 어떻게 잘 관리할 수 있을까?"

에서 비롯된 클러스터 환경에서 컨테이너를 관리하는 소프트웨어이다.

밑의 도표를 통해 더 쉽게 발전흐름도를 알아볼 수 있다.

출처: Fast Campus Kubernetes와 Docker로 한 번에 끝내는 컨테이너 기반 MSA

참고 : https://ko.wikipedia.org/wiki

"kernel"은 운영체제의 핵심 부분으로, 시스템의 모든 부분을 통제한다.

< 통신 조절 >

하드웨어와 소프트웨어 사이 정보 교환을 관리 한다. 

여기서 소프트웨어는 운영체제의 커널을 포함한 다양한 프로그램을 의미한다. 하드웨어는 CPU,Memory,Disk,Network 장치 등을 포함한다. 프로그램이 실행되면서 발생하는 다양한 요청을 하드웨어로 전달하고, 그에 따른 하드웨어의 반응을 다시 프로그램에 전달하는 것이 통신 조절의 핵심이다. 예를 들어, 프로그램이 파일을 저장하려고 할 때,이 요청은 커널을 통해 디스크에 전달되고, 디스크에서 쓰기 작업이 완료되면 커널이 다시 프로그램에 결과를 알려준다.

< 커널의 자원 관리 기능 >

컴퓨터 시스템의 여러 부분을 관리하고 최적화하는 역할을 한다. 이를 통해 컴퓨터가 원활하게 작동할 수 있도록 한다.
프로세스 스케줄링: 컴퓨터에서 여러 프로그램이 동시에 실행될 때, 커널은 어떤 프로그램에 CPU(중앙처리장치)의 시간을 할당할지 결정합니다. 이것을 '스케줄링'이라고 합니다. 예를 들어, 웹 브라우저를 열고 동시에 음악을 듣는다면, 커널은 CPU 시간을 두 프로그램 사이에서 공정하게 분배합니다.

                                                                                                                                              
CPU 시간은 컴퓨터에서 프로그램이 CPU(중앙 처리 장치)를 사용하여 작업을 처리하는 데 소비하는 시간을 의미한다.

컴퓨터에서 여러 프로그램이 동시에 실행되면, CPU는 이들 모든 프로그램에게 시간을 할당해야 한다. 이를 '시분할'이라고 부르며, 이것이 가능하게 해주는 것이 운영체제의 커널이다. 커널은 스케줄러를 통해 CPU의 시간을 어떤 프로그램에게 할당할지 결정한다.

예를 들어, 워드프로세서와 웹 브라우저를 동시에 실행하면 커널은 CPU의 시간을 두 프로그램 사이에서 나누어 준다. 이로 인해 사용자는 두 프로그램이 동시에 실행되는 것처럼 느끼게 된다. 이런 방식을 통해 컴퓨터는 여러 작업을 동시에 처리하는 것처럼 보이는 '멀티태스킹'을 수행한다.

< 메모리 관리 > 

커널은 컴퓨터의 메모리를 관리한다. 프로그램이 실행되면, 커널은 해당 프로그램에 필요한 메모리 공간을 할당하고, 프로그램이 종료되면 그 메모리를 회수한다. 이것은 컴퓨터의 메모리를 효율적으로 사용하도록 도와준다.

< 디바이스 드라이버와의 통신 >

커널은 하드웨어(예: 프린터, 마우스, 키보드 등)와 소프트웨어 사이에서 통신을 중개한다. 이를 위해 커널은 디바이스 드라이버라는 특별한 프로그램을 사용한다. 디바이스 드라이버는 특정 하드웨어 장치를 제어하는 방법을 알고 있는 소프트웨어이다.

따라서, 커널의 자원 관리는 컴퓨터 시스템에서 여러 작업이 원활하게 진행될 수 있도록 돕는 중요한 역할을 한다.

< 보안 >

커널은 시스템의 보안을 책임지며, 하드웨어와 프로세스 사이에서 발생할 수 있는 보안 위협을 관리한다.

< 추상화 >

커널은 운영 체제의 복잡한 내부를 감추고, 깔끔하고 일관성 있는 인터페이스를 하드웨어에 제공하기 위해 몇 가지 하드웨어 추상화를 구현한다. 이를 통해 프로그램은 복잡한 하드웨어 세부 사항을 걱정할 필요 없이 자신의 작업에 집중할 수 있다.

Docker 컨테이너는 이러한 커널을 호스트 운영체제와 공유한다.

즉, 컨테이너 내에서 실행되는 프로그램이 하드웨어와의 통신을 요구하면, 이 요구는 호스트 운영체제의 커널을 통해 처리된다. 이로 인해 Docker 컨테이너는 가상 머신과는 달리, 각각의 컨테이너에 별도의 운영체제를 설치할 필요가 없게 되어 자원을 훨씬 더 효율적으로 활용할 수 있다. 결국 Docker 컨테이너는 호스트 운영체제의 커널을 공유함으로써, 각 컨테이너가 독립적인 환경을 유지하면서도 필요한 자원을 최소화하는 데 도움을 준다. 이러한 특성은 Docker 컨테이너가 높은 성능과 효율성을 가질 수 있게 된다.

Devops가 걸어온 길

Devops => Developer + Operation 합성어

개발과 운영의 경계를 허물고 통합하고자 하는 문화 또는 철학

소프트웨어 개발 프로세스와 운영의 모든 단계의 통합과 자동화를 목표로 한다.

분리된 형태의 운영진영,개발진영의 요구에 따라 벽이 높아져 갔는데

Agile이 등장 함으로써 짧은 주기로 개발 하고 빠른 피드백을 통해 하나의 큰 프로젝트를 만드는 개발 방법론 으로, 지속적인 협력과 피드백을 할려는 노력이 지속 되고,

2009년 공식적으로 Devops라는 용어가 쓰이기 시작했다.

현재는 Public Cloud의 서비스의 발전과 함께 문화나 기술이 진화를 거듭하고 있고,

개발과 운영이 하나로 되어 있는 뫼비우스 띠 형태를 하고 있다.

그리고 그 진화 속에 DevSecOps라는 용어가 탄생했다.

DevSecOps란 Developer + Security + Operation의 합성어 이며,

소프트웨어 개발 프로세스의 모든 단계를 통합하고 보안까지 포함하도록 확장한 개념이다.

소프트웨어 배포에 관여하는 모든 사람들이 보안을 최우선으로 하는 문화 이다.

DevSecOps는 하나의 문화 이기 때문에, 이를 수용하기 위해 개발팀과 운영팀을 대상으로 보안 교육,보안 문제를 신속히 공유할 수 있는 채널을 구축 및 보안 사고 대응 플레이 북, 배포 프로세스에 보안감사/규정준수를 포함시킬 수 있어야 한다.

지금까지 알려진 기업 중 Devops 적용 사례 중 가장 잘 알려진 기업은 넷플릭스 이다.

넷플릭스는 2016년부터 Cloud Native 방식으로 시스템을 재구축하며 Devops 환경을 구축 하였다. 기존의 Netfilx의 생명 주기는

이렇게 각 단계 별로 구분이 되어 있었고, 이 단계는 소통과 협업의 어려움이 있었고 이 단계를 모두 통합 해서 Full-Cycle-Developer-model을 제시 했다.

이를 구현하기 위해 Netflix는 CI/CD,MSA,IAC,Monitoring,Communication을 강조하고 이를 실행 했다. 여기까지 Dev 적용 사례를 살펴 보았으며

Dev의 역사와 정의를 알아보았다.

출처: FastCampus

기존 인프라와 차이점/글로벌 인프라

출처: FastCampus