목차

1. Docker의 단점
2. Kubernetes 시작
3. Kubernetes란?
4. Kubernetes 구성
5. Kubernetes 핵심 기능
6. 마치며

Docker의 단점

이전에 우리는 Docker를 사용하기까지 과정과 Docker에 대해서 알아보았습니다. 하지만 그렇게 유용한 Docker도 점점 시스템에 배포 가능한 애플리케이션 구성 요소의 수가 많아짐에 따라 모든 구성 요소의 관리가 더욱 어려워졌고, 이로 인해 수천 개의 소프트웨어 구성 요소를 관리하고 비용 효율적으로 개발, 배포할 수 있는 솔루션을 개발해야만 했습니다. 다음은 해당 내용 외에 Docker의 단점을 조금 모아보았습니다.

1. 학습 곡선
   Docker는 컨테이너화 및 DevOps 관행에 익숙하지 않은 사람들을 위해 가파른 학습 곡선을 가질 수 있습니다.
   
   
2. 보안
   컨테이너는 호스트 운영 체제의 커널을 공유합니다. 즉, 하나의 컨테이너가 손상되면 동일한 호스트의 다른 컨테이너도 취약해질 수 있습니다.
   
   
3. 리소스 오버헤드
   실행 중인 컨테이너는 호스트 시스템의 성능에 영향을 미칠 수 있는 상당한 양의 리소스를 소비할 수 있습니다.
   
   
4. 복잡성
   Docker는 애플리케이션의 패키징 및 배포를 단순화하지만 특히 대규모 환경에서 전체 시스템 아키텍처에 복잡성을 추가할 수 있습니다.
   
   
5. 무분별한 이미지 확산
   도커 이미지는 빠르게 축적되어 관리하기 어려워져 "이미지 무분별한 확산"이라는 현상이 발생합니다.
   
   
6. 제한된 이식성
   Docker 컨테이너는 여러 운영 체제 간에 이식 가능하지만 시스템 아키텍처 및 커널 버전의 차이로 인해 이식성에 여전히 몇 가지 제한이 있습니다.
   
   
7. 볼륨 관리
   Docker 컨테이너에서 영구 데이터를 관리하는 것은 어려울 수 있습니다. 컨테이너를 삭제하거나 다시 빌드할 때 데이터가 손실되지 않도록 컨테이너 외부에 데이터를 저장해야 하기 때문입니다.

Kubernetes 시작

오랫 동안 구글은 보그(Borg)라는 내부 시스템을 개발해 애플리케이션 개발자와 시스템 관리자가 수천 개의 애플리케이션과 서비스를 관리하는 데 도움을 줬습니다. 개발과 관리를 단순화할 뿐 아니라 인프라 활용률을 크게 높일 수 있었는데, 이는 조직이 그만큼 클 때 중요해집니다. 사용률이 조금만 올라도 수백만 달러가 절약되므로 이런 시스템의 필요성을 충분했습니다.

이후 구글은 10년 가량 보그와 오메가를 비밀로 유지하다 2014년 보그, 오메가, 기타 내부 구글 시스템을 경험을 바탕으로 오픈 소스 시스템인 쿠버네티스를 출시했습니다.

Kubernetes란?

Kubernetes는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하도록 설계된 오픈 소스 컨테이너 오케스트레이션 플랫폼입니다. 원래 Google에서 개발했으며 현재 CNCF(Cloud Native Computing Foundation)에서 관리하고 있습니다.

일반적으로 "K8s"라고 하는 Kubernetes는 분산 시스템의 원칙을 기반으로 하며 여러 호스트에서 컨테이너화된 워크로드를 관리하는 데 사용되어 자동 확장, 자가 복구 및 로드 밸런싱을 제공합니다. 이를 통해 개발자는 애플리케이션을 쉽게 배포, 관리 및 확장할 수 있으므로 클라우드 네이티브 애플리케이션을 구축하고 배포하는 데 널리 사용됩니다.

Kubernetes는 단일 컴퓨팅 리소스를 형성하기 위해 함께 그룹화되는 물리적 또는 가상 머신일 수 있는 노드의 클러스터를 생성하여 작동합니다. 이러한 노드는 노드에 대한 컨테이너 예약 및 배포, 상태 모니터링, 확장 및 로드 밸런싱 관리를 담당하는 컨트롤 플레인에서 관리합니다.

Kubernetes의 주요 기능 중 하나는 자동 확장 및 자가 복구를 포함하여 컨테이너화된 애플리케이션의 관리를 자동화하는 기능입니다. 즉, 컨테이너가 실패하거나 종료되면 Kubernetes는 애플리케이션이 계속해서 원활하게 실행되도록 다른 노드에서 컨테이너를 자동으로 다시 시작합니다.

또한 Kubernetes는 개발자가 고도로 확장 가능하고 유연한 방식으로 애플리케이션을 관리할 수 있도록 하는 풍부한 API 및 도구 세트를 제공합니다. 여기에는 업데이트 롤링, 버전 관리 및 업데이트 롤백을 위한 도구와 서비스 검색, 로드 밸런싱 및 스토리지에 대한 기본 제공 지원이 포함됩니다.

* 참고로 K8s는 K ubernete s. 즉, K와 s 사이에 8개의 알파벳이 있어서 이렇게 표현합니다.

Kubernetes 구성

가장 간단한 구성으로는 하나의 마스터 노드와 여러 워커 노드로 구성됩니다. 개발자가 애플리케이션 매니페스트를 마스터에 게시하면 쿠버네티스는 해당 애플리케이션을 워커 노드 클러스터에 배포합니다. 구성 요소가 어떤 노드에 배포되는지는 개발자나 시스템 관리자에게 중요하지 않습니다. 따로 설정하지 않아도, 현재 가장 적은 양을 가지고 있는 노드로 자동으로 분배가 되기 때문이죠.

개발자는 특정 애플리케이션이 함께 실행되도록 지정할 수 있고 쿠버네티스는 여러 애플리케이션을 동일한 워커 노드에 배포합니다. 다른 애플리케이션은 클러스터에 걸쳐서 분산되지만 배포된 위치에 상관없이 동일한 방식으로 서로 통신할 수 있습니다.

Kubernetes 핵심 기능

1. 개발자가 애플리케이션 핵심 기능에 집중할 수 있도록 해줍니다.
   쿠버네티스는 클러스터의 운영체제로 생각할 수 있지만 애플리케이션 개발자가 특정 인프라 관련 서비스를 애플리케이션에 구현하지 않아도 됩니다. 대신 쿠버네티스에 의존해 이런 서비스를 제공하고 있습니다. 여기에는 서비스 디스커버리, 스케일링, 로드밸런싱, 자가 치유, 리더 선출 같은 것들이 포함됩니다. 따라서 애플리케이션 개발자는 애플리케이션의 실제 기능을 구현하는 데 집중할 수 있으며 애플리케이션을 인프라와 통합하는 방법을 찾는 데 시간을 낭비하지 않아도 됩니다.
   
   
2. 운영 팀이 효과적으로 리소스를 활용할 수 있도록 해줍니다.
   쿠버네티스는 클러스터 어딘가에 컨테이너화된 애플리케이션을 실행하고 구성 요소 간에 서로를 찾는 방법에관한 정보를 제공하고 모든 애플리케이션을 계속 실행하게 합니다. 애플리케이션은 어떤 노드에서 실행되든 상관이 없기 때문에 쿠버네티스는 언제든지 애플리케이션을 재배치하고 애플리케이션을 조합함으로써 리소스를 수동 스케줄링보다 훨씬 더 잘 활용할 수 있습니다.

여기까지 컨테이너의 전후를 알아보았고, 간단하게(?) 도커와 쿠버네티스에 대해서도 알아보았습니다. 이제 도커 실습과 명령어 정리, 쿠버네티스의 더 깊은 이론과 기능들은 각각 카테고리에서 다룰 예정입니다.

근 1달 조금 넘는 기간동안 에티버스 러닝에서 하이브리드 클라우드 교육을 받으면서 "내가 정말 클라우드를 할 수 있을까?" 싶은 생각이 정말 많이 들었습니다. 어렵기도 어렵거니와 각 배운 내용이 어디에 사용되는지 또, 이제야 클라우드의 테두리에 발을 디뎠기 때문에 저번주까지만 해도 클라우드가 감조차 오지 않았었죠.

그런데 이번주부터 배우는 컨테이너 시스템부터 뭔가 클라우드의 테두리가 그려지는 느낌입니다. 뭔가 가슴속 응어리가 조금씩 풀어지는 듯한 느낌이라 기분이 좋습니다. 뭐든 꾸준히 하면 점차 빛을 본다는 게 완전히 틀린 말은 아닌가 봅니다.

블로그를 계속 작성하고 있지만 애드센스가 떨어져 변화를 주고 있는데, 이번 컨테이너 시리즈 제목이 굉장히 만족스럽습니다. 포스팅 200개에 다달아가며 이 작명 센스도 늘어나나 봅니다. 이것을 읽는 독자분들은 어떤지 잘 모르겠지만요. 이번주는 전환점이 되는 포인트인 듯한 느낌입니다. 이번 마무리도 역시 모든 독자분들, IT 업계 종사자들 모두 화이팅입니다. 감사합니다.

p.s 최근 알아야할 정보의 양이 늘어나며 실습이 아닌 이론 위주의 포스팅이 되고 있습니다. 이 부분은 정말 죄송하게 생각하고 있고, 학습이 마무리되고 프로젝트로 넘어가면 실습 위주 포스팅이 가능할 듯합니다. 더 양질의 정보를 제공할 수 있도록 노력하겠습니다. 다시 한번 감사합니다.

목차

1. Docker란?
2. Docker 개념
3. 개발자가 Docker를 사용하는 과정
4. Docker 이미지 레이어
5. 컨테이너의 한계
6. 마치며

Docker란?

Docker는 2013년에 처음 등장한 컨테이너 기반 가상화 도구입니다. 이를 통해 컨테이너를 쉽게 관리하고 이미지를 생성하여 외부 서버에 배포할 수 있습니다. Docker는 애플리케이션을 빠르게 구축, 테스트 및 배포할 수 있는 소프트웨어 플랫폼입니다. Linux 컨테이너를 생성하고 사용할 수 있게 해주는 컨테이너화 기술입니다. Docker를 사용하면 가상 머신과 같은 독립적인 실행 환경을 만들 수 있지만 실제로 운영 체제를 설치하지 않고도 설치 크기가 작아지고 실행 속도가 빨라집니다.

Docker는 Docker 엔진, Dockerfile 및 Docker 허브를 비롯한 다양한 구성 요소로 구성됩니다. Docker 엔진은 컨테이너를 구축, 실행 및 관리할 수 있게 해주는 핵심 구성 요소입니다. Dockerfile은 Docker 이미지 생성을 자동화하는 스크립트입니다. Docker 허브는 Docker 이미지용 리포지토리로, 미리 빌드된 이미지를 찾거나 자신의 이미지를 업로드하여 다른 사람과 공유할 수 있습니다.

Docker의 주요 이점 중 하나는 응용 프로그램 및 서비스를 쉽게 생성, 관리 및 배포할 수 있습니다는 것입니다. Docker를 사용하면 종속성 및 구성을 포함하여 애플리케이션을 실행하는 데 필요한 모든 것이 포함된 이미지를 만든 다음 Docker가 설치된 모든 서버에 배포할 수 있습니다. Docker 컨테이너는 이식 가능합니다. 즉, 기본 운영 체제나 하드웨어에 관계없이 모든 시스템에서 동일한 컨테이너를 실행할 수 있습니다.

Docker 개념

Docker는 애플리케이션을 패키징, 배포, 실행하기 위한 플랫폼입니다. 애플리케이션을 전체 환경과 함께 패키지화할 수 있습니다. 애플리케이션에서 필요한 몇 가지 라이브러리나 운영체제의 파일 시스템에 설치되는 모든 파일을 포함시킬 수 있습니다. Docker를 사용하면 이 패키지를 중앙 저장소로 전송할 수 있으며, Docker를 실행하는 모든 컴퓨터에 전송할 수 있습니다.

Docker의 주요 3가지 개념은 다음과 같습니다.

1. 이미지
   애플리케이션과 해당 환경을 패키지화한 것 입니다. 여기에는 애플리케이션에서 사용할 수 있는 파일 시스템과 이미지가 실행될 때 실행될 때 실행돼야 하는 실행파일 경로와 같은 메타데이터가 포함돼 있습니다.
   
   
2. 레지스트리
   Docker 이미지를 저장하고 다른 사람이나 컴퓨터 간에 해당 이미지를 쉽게 공유할 수 있는 저장소입니다. 이미지를 빌드할 때 빌드하는 컴퓨터에서 이미지를 실행하거나 이미지를 레지스트리로 푸시(업로드)한 다음 다른 컴퓨터에서 이미지를 풀(다운로드)할 수 있습니다. 일부 공개 레지스트리는 누구나 이미지를 가져올 수 있으며, 비공개 레지스트리는 특정 살마이나 컴퓨터만 액세스할 수 있습니다.
   
   
3. 컨테이너
   Docker 기반 컨테이너 이미지에서 생성된 일반적인 리눅스 컨테이너입니다. 실행중인 컨테이너는 Docker를 실행하는 호스트에서 실행되는 프로세스이지만 호스트와 호스트에서 실행 중인 다른 프로세스와 완전히 격리돼 있습니다. 또 프로세스는 리소스 사용이 제한돼 있으므로 할당된 리소스의 양(GPU, RAM 등)만 사용할 수 있습니다.

개발자가 Docker를 사용하는 과정

Docker 이미지 레이어

Docker 이미지는 이미지 인스턴스를 실행하는 컨테이너의 청사진과 같습니다. 이미지는 서로 위에 쌓인 여러 레이어로 구성되며 각 레이어는 이미지의 다른 부분을 나타냅니다.

케이크처럼 생각하세요. 케이크의 각 층은 다른 재료 또는 구성 요소이며 모두 함께 쌓으면 완전한 케이크가 됩니다. 마찬가지로 Docker 이미지의 각 계층은 이미지에 추가되는 서로 다른 지침 집합을 나타냅니다.

이미지를 기반으로 컨테이너를 실행할 때 Docker는 최상위 계층 아래의 모든 계층에 대해 읽기 전용 파일 시스템을 사용합니다. 최상위 계층은 변경을 허용하는 유일한 계층이므로 컨테이너가 실행되는 동안 변경된 사항은 해당 최상위 계층에 기록됩니다.

이 계층 구조는 Docker 이미지를 효율적으로 만듭니다. 일부 계층이 로컬에 이미 캐시되어 있는 경우 Docker가 매번 처음부터 시작하는 대신 해당 계층을 재사용하여 새 이미지를 빌드할 수 있기 때문입니다. 즉, 더 적은 디스크 공간으로 더 빠르게 이미지를 구축하고 배포할 수 있습니다.

컨테이너의 한계

"컨테이너 이미지의 제한된 이식성" 이라고 표현하는 이 유형은 시스템 또는 플랫폼용으로 생성된 이미지가 다른 유형의 시스템 또는 플랫폼에서 제대로 작동하지 않을 수 있다는 사실을 나타냅니다. 이는 운영 체제 또는 아키텍처와 같은 기본 인프라의 차이 때문입니다.

예를 들어 Linux 기반 시스템용으로 생성된 이미지는 Windows 기반 시스템에서 제대로 작동하지 않을 수 있습니다. 이러한 제한된 이식성은 다른 환경 또는 클라우드 플랫폼 간에 컨테이너화된 애플리케이션을 이동하기 어렵게 만들 수 있으며 다른 시스템 간의 호환성을 보장하기 위해 추가적인 노력이 필요할 수 있습니다.

그러나 컨테이너화는 기존의 모놀리식 애플리케이션에 비해 여전히 더 높은 수준의 이식성을 제공합니다. 종속성 및 런타임 환경이 이미지 자체 내에 패키징되어 다양한 호스트 및 환경 간에 애플리케이션을 더 쉽게 이동할 수 있기 때문입니다.

이러한 특징을 가지고 있는 Docker는 점점 사용량이 많아지면서, 보안, 복잡성 등 여러 문제에 직면하게 되었습니다. 이에 따라 이 문제들을 해결할 수단을 개발하게 되는데 그것이 바로 "쿠버네티스"입니다. 다음 시간에는 도커의 문제점과 쿠버네티스에 대해 알아보도록 하겠습니다. 오늘도 읽어주신 모든 여러분들께 감사합니다.

목차

1. 컨테이너 도입 계기
2. 컨테이너 격리 기술의 원리
3. 컨테이너와 가상화 머신 각각의 특징
4. 컨테이너를 다루는 시스템

컨테이너 도입 계기

애플리케이션이 적은 수의 커다란 구성 요소로만 이뤄졌을 때에는 각 구성 요소에 전용 가상 머신을 제공하고 고유한 운영체제 인스턴스를 제공해 환경을 격리할 수 있었습니다. 하지만 이런 구성 요소가 점점 작아지고 숫자가 만하지기 시작하면서 하드웨어 리소스를 낭비하지 않으면서 비용을 줄일 수 있는 방안을 찾아야 했고, 비용을 줄이기 위해 각 구성 요소마다 가상 머신 없이 제공하기 시작했습니다.

이것은 리소스 낭비를 줄이는 것 뿐만 아니라 각각의 가상 머신을 개별적으로 구성하고 관리하는 시스템 관리자의 작업량을 줄이고 이에 따라 인적 자원 낭비도 막을 수 있었습니다.

컨테이너 격리 기술의 원리

1. 리눅스 네임스페이스(namespace)
   기본적으로 각 리눅스 시스템은 초기 구동 시 하나의 네임스페이스가 있습니다. 파일 시스템, 프로세스 ID, 사용자 ID, 네트워크 인터페이스 등과 같은 모든 시스템 리소스는 하나의 네임스페이스에 속합니다. 또 네임스페이스는 기본 네임스페이스에만 국한되지 않고 추가 네임스페이스를 생성하고 리소스를 구성할 수 있습니다.
   
   프로세스를 실행할 때 해당 네임스페이스 중 하나에서 프로세스를 실행합니다. 프로세스는 동일한 네임스페이스 내에 있는 리소스만 볼 수 있는데, 여러 종류의 네임스페이스가 있기 때문에 프로세스는 하나의 네임스페이스에만 속하는 것이 아닌 여러 네임스페이스에 속할 수 있습니다.
   
   네임스페이스의 종류는 다음과 같습니다. 하지만 이뿐 아니라 다른 네임 스페이스들도 있다는 것을 명심해야 합니다.
   1. 마운트(mnt)
   2. 프로세스 ID(pid)
   3. 네트워크(net)
   4. 프로세스 간 통신(ipc)
   5. 호스트와 도메인 이름(uts)
   6. 사용자 ID(user)
   우리가 앞으로 배울 쿠버네티스에서 네임스페이스를 사용하면, 같은 이름의 Service를 다른 네임스페이스에서 사용할 수 있으므로, 개발, 스테이징, 프로덕션 등 여러 개발 환경에서 동일한 구성을 사용할 수 있습니다.
   
   
2. 프로세스 가용 리소스 제한
   컨테이너가 사용할 수 있는 시스템 리소스의 양을 제한하는 것은 리눅스 커널 기능인 cgroups로 이루어집니다. 이를 통해 프로세스는 설정된 양 이상의 CPU, 메모리, 네트워크 대역폭 등을 사용할 수 없습니다. 이런 방식으로 프로세스는 다른 프로세스용으로 예약된 리소스를 사용할 수 없으며, 이는 각 프로세스가 별도의 시스템에서 실행될 때와 비슷합니다.

컨테이너와 가상화 머신 각각의 특징

• 가상 머신(VM)
  
  
  1. VM은 프로세서, 메모리, 스토리지 및 네트워크 리소스를 포함한 전체 하드웨어 스택을 가상화합니다.
  2. 각 VM은 호스트 OS와 다를 수 있는 자체 전체 운영 체제(OS)를 실행합니다.
  3. VM은 서로 격리되어 있어 강력한 보안 및 장애 격리를 제공합니다.
  4. VM은 전체 OS가 필요하기 때문에 컨테이너에 비해 오버헤드가 높아 크기가 커지고 시작 시간이 느려집니다.
  5. VM은 가상 하드웨어를 관리하고 VM에 리소스를 할당하는 소프트웨어 계층인 하이퍼바이저에 의해 관리됩니다.
  6. VM은 완전한 OS 격리가 필요한 애플리케이션이나 OS 요구 사항이 다른 애플리케이션을 실행하는 데 더 적합합니다.
     
     
• 컨테이너
  
  
  1. 컨테이너는 OS를 가상화하여 호스트와 동일한 OS 커널을 공유하지만 네임스페이스라고 하는 격리된 환경에서 실행됩니다.
  2. 컨테이너에는 전체 OS가 필요하지 않으므로 VM에 비해 크기가 작고 시작 시간이 더 빠릅니다.
  3. 컨테이너는 프로세스 수준에서 서로 격리되어 일정 수준의 보안 및 결함 격리를 제공하지만 VM만큼 강력하지는 않습니다.
  4. 컨테이너는 호스트 OS 커널을 공유하고 필요한 애플리케이션 종속성만 포함하므로 VM에 비해 오버헤드가 낮습니다.
  5. 컨테이너는 컨테이너 인스턴스 생성, 실행 및 관리를 담당하는 Docker 또는 containerd와 같은 컨테이너 런타임에 의해 관리됩니다.
  6. 컨테이너는 배포에 더 적합합니다.

이 중 큰 차이점은 애플리케이션이 CPU를 사용할 때 VM은 하이퍼바이저를 거쳐, 가상 CPU를 거쳐, 커널을 거치고, 애플리케이션으로 이동하는 단계를 거치지만, 컨테이너는 커널에서 바로 애플리케이션으로 연결됨으로 엄청난 속도, 용량에서 차이가 납니다.

컨테이너를 다루는 시스템

컨테이너 기술은 오랫동안 사용돼 왔는데, 도커 컨테이너 플랫폼의 등장으로 더 널리 알려지게 되었습니다. 도커는 컨테이너를 여러 시스템에 쉽게 이식이 가능하게 만들어준 최초의 컨테이너 시스템입니다. 단순화에는 성공했지만, 한번에 하나씩만 생성 가능한 등 몇몇 단점으로 인해 자동화와 편리성을 증가시켜 개발된 것이 쿠버네티스입니다. 이 2가지는 다음 포스팅에서 더 자세하게 다루어 보도록 하겠습니다.

쉽게 이야기하자면 처음 컨테이너를 쉽게 이용할 수 있도록 만들어준 시스템이 "Docker", 이 Docker를 더 편하게 다룰 수 있도록 만들어준 것이 "Kubernetes"이다. 쿠버네티스는 맨 앞 K와 맨 끝 s 사이에 8개 알파벳이 들어가 "k8s"라고도 합니다.

컨테이너 이전 기술들

컨테이너에 대해 알아보기 전에 우리는 컨테이너 이전에 어떤 시스템을 사용하였고, 그 시스템에 문제점이 있었는지에 대해 알아볼 필요가 있습니다. 컨테이너의 목적도 모른 채 '그런가 보다'하는 것은 적절하지 않고, 이유와 목적을 뚜렷하게 알고 있으면 좀 더 생산적인 업무 효율로 반증될 테니 말이죠.

• monolithic virtual machine
  
  이전에 대부분의 소프트웨어 어플리케이션들은 하나의 프로세스 또는 몇 개의 서버에 분산된 프로세스로 실행되는 거대한 모놀리스(monolith)였습니다. 이 중 모놀리스틱 가상 장치는 전체 운영 체제가 가상화되어 물리적 호스트 장치에서 단일, 독립적인 인스턴스로 실행되는 방식을 말합니다.
  
  하나의 통합된 단위로 구축되어 다른 어플리케이션으로부터 독립적입니다. 이 방식은 전체 운영 체제, 미들 웨어 및 애플리케이션을 포함하며 여러 애플리케이션들을 한 번에 실행하거나 애플리케이션 간 격리, 레거시 애플리케이션 지원에 가장 적합합니다.
  
  하지만 이 장치는 리소스 비효율성, 한계적인 확장성, 제한된 유연성, 장애 발생 위험 증가 및 복잡성 증가와 같은 단점이 있습니다. 각 모놀리식 가상 머신은 전용 리소스 세트가 필요하기 때문에 수요 변화에 신속하게 대응하기 어렵고 하드웨어에 상당한 투자가 필요할 수 있습니다.
  
  또한, 모놀리식 가상 머신은 다른 가상화 유형보다 관리하기 복잡할 수 있으며, 각 가상 머신에는 운영 체제, 미들웨어 및 어플리케이션이 포함되어 있어 문제 해결이 어려울 수 있으며 더 많은 전문 기술과 전문 지식이 필요할 수 있습니다. 이러한 단점들은 점차 마이크로 서비스라는 독립적으로 실행되는 더 작은 구성 요소로 세분화되기 시작했습니다.
• microservice
  
  마이크로서비스(microservice)는 단일 어플리케이션을 여러 개의 작은 컴포넌트 혹은 서비스들로 이루어진, 느슨하게 결합되고 독립적으로 배포 가능한 클라우드 기반의 아키텍처 접근법입니다. 각각의 서비스들은 자체적으로 기술 스택과 데이터베이스와 데이터 관리 모델을 가지고 있으며, 비즈니스 기능을 구현합니다.
  
  이러한 마이크로서비스 아키텍처는 대규모, 복잡한 어플리케이션의 지속적인 배포 및 전달을 용이하게 하며 기술 스택 업데이트에도 적합합니다. 각각의 마이크로서비스들은 더 작은 단위로 개발되고, 독립적으로 배포될 수 있어 개발자들이 일부분만 수정하고 배포할 수 있습니다.
  
  이는 개발 효율성을 높이고, 유지보수를 용이하게 합니다. 마이크로서비스는 SOA(Service Oriented Architecture)와 비슷한 개념이지만, SOA가 다수의 웹 서비스를 묶어 하나의 애플리케이션으로 제공하는 것과 달리, 마이크로서비스는 하나의 애플리케이션을 여러 개의 서비스로 나누어 독립적으로 제공합니다. 또한, 마이크로서비스는 기존의 단일 애플리케이션 모놀리스(monolith)와 비교하여 기술 다양성, 오류 격리 등 다양한 장점을 가지고 있습니다.
  
  하지만 이런 마이크로서비스도 여러 단점들이 있습니다.
  1. 작업 구성이 복잡하며, 자동 배포가 필요합니다.
  2. 어플리케이션을 한 부분만 변경하더라도 전체 애플리케이션을 재배포해야 합니다.
  3. 컨텍스트 경계를 넘나드는 번역이 필요합니다.
  4. 분산 시스템과 관련된 모든 복잡성이 있으며, 서로 다른 서비스 간 통신 중 실패할 가능성이 높습니다.
  5. 대규모 서비스를 관리하기 어렵습니다.
  6. 개발자가 직접 네트워크 지연 및 부하 분산과 같은 문제를 해결해야 합니다.
• DevOps
  
  해당 포스팅에서는 데브 옵스를 간단하게 다루지만 기회가 된다면 더 자세히 다루도록 하겠습니다. 위와 같은 문제를 해결하기 위해 전체 애플리케이션 개발 프로세스와 프로덕션 환경에서 관리 방식이 점차 변경되었는데, 이전에 개발팀에서 애플리케이션을 배포하여 운영 팀에 넘겨주는 것 이었으나, 점차 개발 팀 자체적으로 배포하고 관리하는게 더 효율적이라는 것을 깨달았습니다. 즉, 개발자, QA, 운영 팀이 전체 프로세스에서 협업이 진행되어야 한다는 뜻이고, 이러한 방식을 DevOps라고 합니다.
  
  데브 옵스는 운영, 개발이 같이 이루어지면서 다음과 같은 장점을 갖게 되었습니다.
  1. 개발자가 프로덕션 환경에서 어플리케이션 실행에 더 많은 관여를 하게 되면서 사용자가 무엇을 필요로 하고 어떤 문제가 있는지 더 잘 이해할 수 있고, 빠른 피드백으로 고객 만족도를 높일 수 있습니다.
  2. 최신 버전 어플리케이션을 자주 릴리스하려면 배포 프로세스를 간소화해야 하는데, 팀이 나누어져 있을 때 보다 더 빠르게 의견을 주고받으며, 빠른 릴리스를 가능하게 합니다.
• NoOps
  
  데브 옵스에서 개발자들이 배포를 하기 위해서는 하드웨어 인프라를 알고 있어야 했지만, 많은 개발자들은 알고 싶어 하지 않았다고 합니다. 때문에 하드웨어 인프라를 알지 못해도 개발자가 운영팀을 거치지 않고 애플리케이션을 배포하기 위한 방식을 선택한 것이 바로 NoOps입니다.
  
  이러한 특징 덕분에 개발자는 애플리케이션 개발에 더 집중할 수 있으며, 더욱 신속한 배포 프로세스를 구성할 수 있습니다. 누군가가 하드웨어를 관리할 필요는 있지만, 이상적으로는 그 위에서 실행되는 각 애플리케이션의 특성을 다루지 않아도 됩니다.
  
  이러한 것들을 바람과 문제 해결을 하기 위해 쿠버네티스를 개발 및 활용되게 되었고 여기에서 사용되는 기술이 바로 컨테이너 기술입니다.

목차

1. Docker 설치
2. 순서
3. 상태 확인
4. 오류
5. 마치며

Docker 설치

이번 컨테이너 강의에서부터 Ubuntu OS로 변경되어 기준이 Ubuntu로 진행될 것이다. RadHat기반은 apt-get 대신 yum이나 dnf로 바꿔주고 그대로 진행해주면 됨으로 걱정하지 않아도 된다.

순서

1. 업데이트
   sudo apt-get update
   
   
2. 설치 목록
   • apt-transport-https
   • ca-certificates
   • curl
   • software-properties-common
3. 설치 명령어
   • sudo apt-get install -y apt-transprot-https ca-certificates curl software-properties-common
4. GPG키 추가
   • curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
5. Docker 공식 저장소를 리포지토리로 등록
   • add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
6. 리포지토리 갱신
   • sudo apt-get update
7. Docker Container engine 설치
   • apt-get install -y docker-ce

상태 확인

1. systemctl status docker (정상 작동이 되고 있는지 확인)
2. docker version(설치되어 있는 docker 버전 확인)

오류

처음 E를 보면 It is held by process XXXX처럼 프로세스 넘버가 나올 것이다. 이 번호가 문제를 일으키고 있음으로 제거해 주면 이어서 다운로드가 가능하다. 따라서 이와 같은 오류가 나올 때는 다음 명령어를 입력해준다.

• kill -9 12117

오늘부터 과목이 변경되고, 구글 애드센스에서 탈락되며 블로그 작성방법 변경에 들어갔다. 이전 블로그 포스팅 방식과 현 포스팅 방식 사이에 어떤 것이 좋은지 피드백 해주시면 그에 따라 포스팅 방식을 다시 변경하도록 하겠다. 또 다른 오류가 발견된다면 질문해주시길 바란다. 나도 함께 찾아서 포스팅하도록 하겠다.

컨테이너 과목에 들어가면서 Docker, Kubernetes 등 과목이 엄청나게 어려워지고 복잡도도 증가했다. 또한 이 과목을 진행하기 위해서는 이전에 포스팅했던 네트워크, 리눅스에 대한 이해를 필수로 해주어야 한다. 이제 리눅스를 넘어 클라우드에 한걸음 내딛게 되었다. 모든 IT 업계 종사자들을 응원한다. 화이팅이다!