코린이형준

적응하기 힘든 속도로 소프트웨어 아키텍처는 상당한 변화를 겪어왔고 현재 그 속도는 더욱 가파르게 진화하고 있습니다.

개인적인 생각으로 큰 변화로 다가왔고 앞으로 많은 영향을 끼친 아키텍처는 서버리스 였다고 생각합니다.

그렇다면 서버리스란 무엇이고 무슨 이점때문에 사용하는것일까요?

서버리스 컴퓨팅 이란 무엇인가요?

서버가 있지만 서버가 없는것처럼 개발하고 운영한다.

처음 서버리스에 대해 접했을 때, 이전 회사의 CTO님이 말씀해주셨고 지금와서보면 가장 적합한 설명이라 생각합니다.

말 그대로 특정 요구사항에 대해서 해결을 위한 개발만 하고 그 외의 다른 부분은 크게 신경 쓰지 않아도 관리가 되는 아키텍처입니다.

즉, 개발자는 서버에 대한 인프라를 관리할 필요가 없으며, 필요한 코드만 작성하고 해당 코드만 배포합니다.

무엇이 다른가요?

이전 회사에서 모놀리식 기반의 서버를 운영했고, 마이크로서비스를 점차 도입하다 나왔으며 현재 회사에서는 서버리스를 운영하고 있는 찍먹 개발자의 지극히 개인적인 입장에서 각 아키텍처의 장단점에 대해 써보겠습니다. 

모놀리식

장점

1. 간단한 구조: 하나의 서버 운영으로 모든 기능을 구현할 수 있습니다.
2. 개발 및 유지보수의 용이성: 하나의 서버로 개발 및 유지보수가 간단합니다.

단점

1. 확장성의 한계: 애플리케이션의 크기가 커지면 확장이 어려워질 수 있습니다.
2. 장애의 전파: 하나의 컴포넌트의 장애가 전체 시스템에 영향을 미칠 수 있습니다.
3. 기술적 부채: 시간이 지남에 따라 기술적 부채가 쌓일 수 있습니다.

마이크로서비스

장점

1. 모듈화: 각 기능을 독립적으로 개발하고 배포할 수 있습니다.
2. 확장성: 필요한 서비스만 확장할 수 있습니다.
3. 기술적 다양성: 각 마이크로서비스는 독립적으로 기술 스택을 선택할 수 있습니다.

단점

1. 운영의 복잡성: 여러 개의 서비스를 관리해야 하므로 운영이 복잡해질 수 있습니다.
2. 데이터 일관성: 여러 서비스가 동작하기 때문에 데이터 일관성을 유지하기 어려울 수 있습니다.
3. 테스트의 어려움: 여러 서비스 간의 테스트가 복잡해질 수 있습니다.

서버리스

장점

1. 비용 효율성: 사용한 만큼만 과금되므로 비용을 효율적으로 관리할 수 있습니다.
2. 확장성: 자동으로 확장되므로 트래픽 증가에도 대응할 수 있습니다.
3. 유지보수의 용이성: 서버 관리와 업그레이드 등에 대한 걱정이 없어져 개발자는 코드에 집중할 수 있습니다.
4. 빠른 배포: 코드를 더 빠르게 개발하고 배포할 수 있습니다.
5. 자동화된 관리: 인프라 관리가 자동화되어 개발자는 인프라에 대해 신경 쓸 필요가 없습니다.

단점

1. 제한된 실행 환경: 서버리스 환경에서는 실행 환경이 제한되어 일부 라이브러리나 환경 변수를 사용하기 어려울 수 있습니다.
2. 모니터링 및 디버깅의 어려움: 코드 실행과 관련된 모니터링 및 디버깅이 어려울 수 있습니다.
3. 플랫폼 종속성: 특정 클라우드 사의 플랫폼에 종속성을 띈다.
4. 콜드스타트: 하나의 세션이 종료 된 후 일정 시간이 지난 후, 함수 실행시 큰 지연시간이 발생한다.

서버리스, 모놀리식 아키텍처, 마이크로서비스 아키텍처는 각각 장단점이 있으며, 사용하는 상황에 따라 적절한 아키텍처를 선택해야 합니다. 서버리스는 비용 효율성과 개발 생산성을 높일 수 있지만, 실행 환경의 제약과 모니터링의 어려움을 고려해야 합니다.

다만, 서버리스의 경우 이전글에서 설명한 aws cdk와 같은 iac의 등장과 발전으로 인해 1,2,3번의 단점은 충분히 해결 되어 가고 있다고 생각이 듭니다. 하지만 콜드스타트의 경우, 요청이 들어왔을 때만 실행 시키는 서버리스의 컨셉상 가장 지금까지 해결되지 않고 있는 문제점 입니다.

콜드스타트의 해결방법은 없는건가요?

물론 각 클라우드사에서도 해결방법을 제시하고 몇가지 대표적인 방안이 있습니다.

aws의 람다를 기준으로 말씀드리면

1. lambda snapstart

함수의 실행 환경을 실행 시마다 빌드 및 함수 실행의 과정을 거치는것이 런타임 실행전 필요한 실행 환경 시점을 snapshot 형태로 caching 하여 런타임을 실행하는것을 뜻합니다.

다만, 이 컨셉상 java만을 지원하고 있고 당연하게도 python, node의 경우 지원하지 않고 만약 지원한다 하더라도 해당 언어의 특성상 큰 성능 개선은 되지 않을것입니다.

2. warmup

aws lambda의 경우, cold start가 발생하는 시점은 람다 함수를 실행하고 이후 요청이 들어오지 않고 5분이 지난 시점입니다.

즉, cold start를 발생 시키지 않는 방식은 5분이 지나기전에 최소 1회씩 계속해서 함수를 실행 시키는 방식입니다.

물론, 원하는 문제는 해결되겠지만 서버리스의 사용 이유중 큰 장점인 비용 효율성 측면에서 결국 이점을 챙기지 못하는 문제가 발생합니다.

3. scale up

단순합니다. cpu와 ram 사용량을 늘리면 어느정도 개선이 됩니다.

당연하게도 불필요한 과금은 지속되고 기본적인 cold start에 대한 부분의 직접적인 해결책은 아니라고 생각이 듭니다.

그래서 해결책이 무엇이냐고요?

개인적인 의견으로는 현재로써는 답은 없다고 생각됩니다. 여러 방식을 제안하고는 있지만 이러한 노력에도 불구하고 큰 성능 개선 사항은 없고 cold start로 인한 문제가 지속해서 발생한다면 당장은 다른 아키텍처를 고려해보는것이 정답이라고 생각됩니다.

그저 서버리스의 특성상 각자 사용하는 클라우드 플랫폼에서의 개선을 기다리는게 답이라는 생각이 듭니다.

결론

서버리스는 현재 가파르게 성장하고 있으며, 앞으로 더 많은 기업들이 서버리스를 채택할 것으로 예상됩니다. 

시장 동향을 보면 현재 AWS, Azure, Google Cloud를 중심으로 한 경쟁이 치열하게 벌어지고 있으며, 이를 통해 서버리스 서비스의 품질과 다양성이 증가할 것으로 기대됩니다. 앞서 말한 큰 문제점인 cold start또한 각 기업들이 문제 파악을 하고 있고 지속해서 성능 개선에 대한 노력을 기울이고 있기 때문에 조만간 개선 될것이라 생각듭니다.

새롭게 마이그레이션 하는 서비스라면 한번 서버리스 아키텍처 도입을 고려해보는것 아주 좋은 선택이라고 생각됩니다.

찐 결론) 서버리스에 대한 빌드업은 끝났다!! 다음글부터 cdk 폭탄글 우수수 떨어집니다!

"cdk 사용경험이 있으신가요?" 

최근 데이터 엔지니어 직무로 전환 이직을 하며 들었던 가장 난감했던 면접 질문이였다.

"그게 뭐죠?"

"그럼 Iac가 뭔지 아시나요?"

"인프라 애즈 코드,,,? 몰라요 죄송합니다."

"..."

이랬는데 합격을 했고 현재 불티나게 cdk를 만지고 있는 잡부 엔지니어 입니다.

이글을 읽는 여러분, cdk에 대해서 어느정도 뭔지 알고 들어오셨을거라 생각합니다.

이참에 한번 느껴보고 갑시다.

Iac가 뭔지 아시나요?

질문에 대해서 저처럼 답변을 했다면, 진정 그 스택의 필요성을 느끼기 힘들것이라 생각합니다.

뭐든 새로운 기술을 접했을때 진정으로 제것으로 만들기 위해서는 특정 상황에서 결핍 또는 불편함을 느껴야합니다.

예를들어 봅시다.



사이드 프로젝트 진행간 대부분 비슷한 환경인 ec2, rds, s3 연동간 이전과 동일한 환경을 구성하는 와중 일부 환경을 실수로 다르게 세팅하거나 반복 작업 자체에 대한 불편함을 느껴본 경험이 있으신가요?

이런 상황 속 해결책이 바로 Iac입니다.

Infra as code: 코드로 인프라를 정의한다.

"한번 잘작성한 코드는 십년은 간다" (feat.코린이형준) 라는 유명한말이있죠.

위에서 정의했던 문제인 동일한 환경이지만 새로운 프로젝트 시마다 계속해서 재구성해야하는 이러한 상황을 방지하고 뿐만아니라 기존의 복잡한 세팅도 실수 하지 않고 동일하게 세팅할 수 있도록 도와주는것이 "Iac"입니다. 

그럼, aws cdk 가 뭔지 아시나요?

자, 여기서 한가지 확인하고 가야할 친구가 있습니다.

바로, 한번 쯤은 들어봤을법한 "Terraform" 바로 이구역의 강자입니다.

resource "aws_vpc" "main" {
  cidr_block = var.base_cidr_block
}


<BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {
  # Block body
  <IDENTIFIER> = <EXPRESSIONS> # Argument
}

위와 같이 HCL 이라는 문법을 사용하여 인프라를 정의합니다. 이 또한 코드로 인프라를 정의할 수 있고 무엇보다 Azure, GCP등 aws 뿐만이 아니라 다양한 클라우드 서비스 또한 지원하기 때문에 멀티 클라우드 환경에서는 대체 할 수 없는 강자라고 볼수 있습니다.

근데, 여기서 또 한가지 불편한점이 있지 않나요?

예, 맞습니다. 우리의 시간은 한정적입니다.

"생각 보다 잦은 변화가 없는 인프라 구조인데 이것 때문에 새로운 언어를 배워야해요?"

"그냥 제가 잘하는 Python, Typescript, Golang, etc...로 정의할 수는 없나요?"

"우리 회사는 aws만 사용하면 되는데요...?"

등등 다양한 불만이 생길 수 있습니다.

이러한 고민을 해결하기 위해 aws 에서 직접 출시한 것이 "aws cdk" 입니다.

어떻게 동작하는가?

사실, cdk는 내부적으로 이전에 aws에서 Iac로써 출시 했던 CloudFormation 템플릿을 정의하여 사용합니다. 

외부에 프로그래밍 언어로 cloudformation 템플릿을 테스트, 구성 및 배포를 진행하는 구조입니다.

(이 챕터에서는 AWS CloudFormation에 대해 다루지 않기 때문에 모르시다면 컨셉만 확인하고 오시면 될것 같습니다.)

간단한 실습을 통해 더욱 자세히 알아가 봅시다.

초기 프로젝트 구조 세팅

기본적으로 cdk에서는 typescript 뿐만 아니라 python, csharp, javascript, java, golang을 지원합니다.

이중 가장 많은 레퍼런스가 있는 typescript로 진행해보도록 하겠습니다.

cdk init --language typescript

S3 Stack 정의

./lib/main.ts

import * as cdk from 'aws-cdk-lib';
import { aws_s3 as s3 } from 'aws-cdk-lib';

export class S3CdkStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    new s3.Bucket(this, 'MyFirstBucket', {
      versioned: true,
      bucketName: 'my-test-bucket-for-hj',
    });
  }
}

부트스트래핑

cdk bootstrap

cdk bootstrap 명령어는 cdk 로인프라를 프로비저닝하기 전에 필요한 초기 설정 작업을 수행하는 역할을 합니다.

CDK 애플리케이션을 배포하기 위해 필요한 리소스(예: S3 버킷, IAM 역할 등)를 포함하는 특정 AWS 계정과 리전에 대한 환경을 준비합니다.

간단히 말해, cdk bootstrap은 CDK를 사용하여 클라우드 리소스를 관리하고 배포하기 위한 기본적인 환경을 설정하는 과정입니다. 이 과정을 통해 생성된 리소스는 CDK 애플리케이션의 배포 과정에서 사용됩니다.

stack 배포 사전 실행

cdk synth

./bin/main.ts 하위 정의된 stack들에 대해서 사전 실행을 합니다.

실제로, 배포 이전 인프라 구성에 사용된 stack들에 대한 테스트를 진행한다고 이해하면 됩니다.

이과정까지 모두 문제없이 진행되었을겁니다.

자, 이제 멋드러진 배포를 진행해봅시다.

stack 배포

cdk deploy

실제로 s3 이름이 중복되지만 않는다면 별 문제 없이 s3 자원이 생성된것을 확인할 수 있습니다.

stack 제거

cdk destroy

배포 된 stack에 포함되어있는 aws 자원을 제거합니다.

후기

실습의 굉장히 간단하게 진행했지만 aws에서 제공하는 api를 활용해 진행하는 만큼 굉장히 신뢰도가 높고 다양한 기능을 제공하고 있습니다. 무엇보다, 유연하게 본인의 주력 언어로 코드를 작성하여 코드를 재사용하고 인프라를 명시적으로 구성할 수 있다는 큰 장점을 가지고 있는 툴이라고 생각됩니다.

단점 또한 존재는 합니다. 레퍼런스가 많지 않고, 공식 문서가 생각보다 불친절한 부분이 있어서 어느정도 구현에 있어서 직접 하나하나 찾아가면서 작성해야한다는 점입니다.

물론, 이러한 단점을 커버할 만큼 프로그래밍 언어로 인프라를 정의할 수 있다는 점에서 앞으로 점차 큰 영향력을 행사하지 않을까?하는 기대감을 가지고 있습니다.

결론: Iac 도입에 대해서 고민을 하고 있다면 cdk 한번 고려해보는것 나쁘지 않은 선택이라고 생각이 듭니다!

언젠가 시간이 된다면, 좀더 딥한 구조의 cdk 실습 리뷰로 찾아뵙겠습니다.

감사합니다!

+) cdk for terraform이라는 cdk의 프로그래밍과 terraform의 멀티클라우드 지원이라는 장점만 모여있는 강려크한 도구가 있습니다. 확인해보시죠!

1.VPN(Virtual Private Network)

인터넷을 활용하여 원격지 간에 암호화 기술을 적용하여 보다 안정적이게 네트워크를 서로 연결하여 데이터를 공유하는 시스템 -> 예로, 재택근무간 컴퓨터를 원격접속할때도 바로 이 VPN이 활용됨

2.amazon vpc(Virtual Private Cloud)

aws 클라우드의 네트워크 공간을 할당하여 가상 네트워크에서 aws 리소스를 이용할 수 있는 서비스

특징

-격리된 자신만의 네트워크를 구성할 수 있다.

-격리된 네트워크는 subnet 관리가 가능하며, 관리자는 인터넷에 노출될 public subnet과 그렇지 않은 private subnet을 나눌 수 있다. 웹 서버등은 public subnet에 두고, 외부로 부터 격리가 필요한 데이터베이스, WAS등은 private subnet에 두는 등의 자오로운 구성이 가능하다.

-라우터를 만들고 설정 할 수 있다. 라우터를 이용해서 패킷의 경로를 재 조정할 수 있다. public subnet에 NAT를 만들고 private subnet의 패킷을 NAT를 경유하게 해서 인터넷 접근이 가능하게 하는 등의 구성이 가능하다.

-VPN을 구성해서 기업의 데이터 센터를 AWS로 확장할 수 있다.

-모든 리전에서 사용 가능하다.

구성요소

-프라이빗 IP: 인터넷으로 접근x, VPC내부에서만 사용가능한 IP

-퍼블릭 IP: 인터넷으로 접근o, 인스턴스 재부팅시 퍼블릭 IP 자동 변경

-탄력적 IP: IP할당후 인스턴스에 연결시 인터넷으로 접근o, 고정된 IP값

-VPC: 개인 사용자 내부의 가상 네트워크망

-서브넷: VPC내부의 더많은 네트워크망을 만들기위해 VPC를 쪼개는 개념

-퍼블릭 서브넷: 인터넷 게이트웨이로 라우팅 되는 서브넷(ex.EC2)

-프라이빗 서브넷: 인터넷 게이트웨이로 라우팅 되지 않는 비교적 보안성을 필요로하는 서브넷(ex.RDS)

-라우터: 네트워크 요청이 발생했을때 데이터가 우선적으로 향하는 곳(목적지)

-라우팅 테이블: 네트워크 요청은 라우팅 테이블에 따라 목적지로 향함(이정표) -> 서브넷의 인스턴스로 연결

주요 서비스

-보안 그룹과 네트워크 액세스 제어 목록(Network ACL)

-VPC 피어링 연결: 서로 다른 두 VPC간에 트래픽을 라우팅할수 있게 하는 서비스

-NAT 게이트웨이: 인터넷 게이트웨이가 연결되지 않은 인스턴스들이 특정 CIDR에 대해서 인터넷 액세스 할수 있도록 변환해주는 서비스(for.소스 IP)

-VPC Endpoint: NAT 게이트웨이를 사용하지 않고도 인터넷 액세스에 대해 S3,rds와 같은 프라이빗 서브넷에 연결 가능하게끔 만들어주는 서비스 -> 내부에서 통신을 허용하게끔 VPC Endpoint를 만들어줌

참고 블로그

1.스토리지(Storage)

- 컴퓨터에 데이터를 저장하는 저장소의 역할을 수행하는 부품(ex.하드디스크)

- 스토리지 -> 서버 or 스토리지용 네트워크 구성

DAS(Direct Attached Storage): 서버에 직접 연결하는 방식

-NAS(Network Attached Storage): 스토리지를 빠른속도의 네트워크로 연결하는 방식

LAN을 연결하여 사용하기 때문에 비용이 저렴하며 파일 단위로 데이터에 접속하기 때문에 OS에서 파일로 표시

-SAN(Storage Area Network): 확장이 용이하며, 빠른 속도의 서비스 제공 및 OS에서 디스크로 표시

--> NAS = S3, SAN = EBS?

2.데이터 백업

-데이터가 손상되거나 유실되는 것을 대비하여 다른곳에 데이터 복사 후 저장

-스냅샷: 특정 시점 원본 데이터와 동일한 복사본을 저장 해둔다(ex. VirtualMachine의 스냅샷)

S3 vs EBS

가장 큰 차이점은 EBS는 블록 스토리지 방식, S3는 객체 스토리지 방식을 사용

3.S3(Simple Storage Services)

특징

-무한대로 저장 가능 -> 사용한 공간 만큼 비용지불

-버킷이라는 리전내에서 유일한 공간 생성

-데이터를 키-값 형식의 객체로 저장

-기본적으로 온라인, HTTP 기반 접근

https://버킷.s3.ap-northeast-2.amazonaws.com/객체/키
S3 버킷 내부의 객체 폴더 안의 키값에 해당하는 이미지 불러오기

S3스토리지 클래스

-S3표준: 자주 액세스하는 데이터를 위한 스토리지(ex. image나 정적 파일(css)등..)

-S3표준-IA:액세스 빈도가 낮지만 필요시 빠르게 필요할때 사용하는 스토리지 클래스(ex. 백업)

-S3 One Zone-IA: S3표준-IA와 동일한 상황에 쓰이지만 S3 표준 또는 S3 표준-IA 스토리지와 같은 가용성 및 복원력이 필요 없는 고객에게 적합(ex. 백업)

-S3 Glacier: 액세스 빈도가 낮지만 필요시 빠르게 검색할때 사용하는 스토리지 클래스, 복원하는데 IA대비 비교적 많은 시간이 걸림!

가격: 표준 > 표준IA > One Zone-IA > Glacier (Glacier은 freetierX)

4.AMI와 amazon marketplace

-AMI: 도커의 이미지와 비슷한 것으로 ec2 인스턴스 생성에 필요한 모든 소프트웨어 정보를 담고있는 템플릿 저장소이며 유저들이 이미지를 만들수도 있다.

-amazon merketplace: OS뿐만 아닌 애플리케이션등 AWS에서 실행되는 소프트웨어를 판매 및 구매할수 있는 서비스

참고 블로그

1.이미지란?

도커에서 서비스 운영에 필요한 서버 프로그램, 소스코드 및 라이브러리, 컴파일된 실행 파일을 묶는 형태를 Image라고 한다. 도커의 실행은 프로세스 실행을 하는것이므로 이 프로세스를 실행하기 위한 모든 파일과 설정값을 지닌것으로, 도커의 주체 즉, 실행할 파일이라고 생각하면 된다. 이미지 파일로 설정할수 있는것들은 mysql, ubuntu, nginx등 이미 만들어져 있는 공식적인 이미지 같은경우, 도커허브(https://hub.docker.com/)에서 모두 확인가능하며 깃허브에 코드를 올리는것과 마찬가지로 개개인이 만든이미지를 업로드하고 공유할수 있다. 그리고 외적으로는 개개인이 새롭게 자신만의 프로젝트를 올릴때는 깃허브와 같은 소스공유 방법을 통해 이미지를 빌드 할수 있다.

2.이미지 만들기

docker build -t corin2/testimage:ver1 .

-docker build -t : 도커 이미지 생성 명령어

-corin2 : 이미지를 생성한 사람의 이름

-testimage : 이미지 이름

-:ver1 : 태그 즉, 버전으로 활용가능

-. : 빌드 컨텍스트 위치로 통상적으로 현재위치인 .을 사용하나 필요에따라 다른 디렉터리를 지정하여도 문제없다.

추가로, .dockerignore파일또한 생성가능한데 .gitignore와 같은 역할로 민감한 정보를 가리는것 외에도 빌드시에 가상환경과 같은 부분을 같이 빌드하지 않기위해서도 사용된다.

즉, 위 명령어를 통해 생성된 이미지로 도커를 실행시킬수 있는것이다. 이미지는 통상적으로 Dockerfile스크립트 파일을 생성해 실행하는데 Dockerfile에 들어가는 명령어는 아래와 같다.

3.Dockerfile 명령어

4.활용

도커 이미지 생성같은경우는 작업 환경에서 직접 빌드하는 방식도 있지만 주로 깃허브에서 소스를 가져와 빌드하는 방법이다. 이방법같은경우, 다음 목차에서 간단한 프로젝트를 가져와 빌드하도록 해보겠다.

ref. 인프런 강의. 초보를 위한 도커 안내서를 보고 참고하여 정리하였습니다.

1.도커 컴포즈란?

일반적인 시스템은 단일 애플리케이션으로 구동이 되지 않습니다. 여러 개의 애플리케이션이 서로 의존성 있게 구성되어 시스템이 이뤄져 있습니다. 그렇다면 흔히 하나의 컨테이너가 하나의 애플리케이션을 담당한다고 하면 여러 개의 컨테이너가 필요로 합니다. 이때 필요한 기술이 도커 컴포즈(Docker Compose)입니다. 도커 컴포즈는 yaml 포맷으로 작성되며 여러 개의 컨테이너의 실행을 한 번에 관리를 할 수 있게 해 줍니다.

2.도커 컴포즈 설치

sudo curl -L "https://github.com/docker/compose/releases/download/1.26.0/
docker-compose-$(uname -s)

3.도커 컴포즈 실행과 종료

-up명령어: 컨테이너 실행

docker-compose up -d

-down명령어: 종료

docker-compose down

4.도커 컴포즈 문법

version: '2' 
services: 
 db: 
   image: mysql:5.7 
   volumes: 
     -./mysql:/var/lib/mysql 
   restart: always 
   environment: 
     MYSQL_ROOT_PASSWORD: wordpress 
     MYSQL_DATABASE: wordpress 
     MYSQL_USER: wordpress 
     MYSQL_PASSWORD: wordpress
 wordpress: 
   image: wordpress:latest 
   volumes: 
     -./wp:/var/www/html 
   ports: 
     -"8000:80" 
   restart: always 
   environment: 
     WORDPRESS_DB_HOST: db:3306 
     WORDPRESS_DB_PASSWORD: wordpress

-version: docker-compose.yml 파일의 명세 버전

version: '2'

-services: 실행할 컨테이너 정의, docker run --name wordpress과 같다고 생각할 수 있음

services:
 db:
 ...
 wordpress:
 ...

-image: 실행할 이미지 태그부분에 버전기입을안할시 자동으로 lastest버전으로 실행

services:
 wordpress:
 image: wordpress:sample

-ports: 컨테이너와 연결할 포트 {호스트 포트}:{컨테이너 포트}

services:
 db:
   ...
   ports:
     - "8000:8000"

-environment: 컨테이너에서 사용할 환경변수 - {환경변수 이름}:{값}

services:
 mysql:
 ...
   environment:
   - MYSQL_ROOT_PASSWORD=somewordpress: '3'

-volumes: 마운트하려는 디렉터리 - {호스트 디렉터리}:{컨테이너 디렉터리}

services:
 django:
 ...
   volumes:
     - ./app:/app

-build: 이미지를 자체 빌드 시 사용 - image속성 대신 사용

django:
 build:
   context: .
   dockerfile: ./compose/django/Dockerfile-dev

그외 logs, stop, start와 같은 기본 명령어는 도커 명령어와 동일!!

ref. 인프런 강의. 초보를 위한 도커 안내서를 보고 참고하여 정리하였습니다.

1.도커 설치

도커는 기본적으로 리눅스 기반에 맞춰 개발환경이 갖춰져있으므로 만약 윈도우 사용자라면 VM으로 우분투를 설치하여 사용하길 권장합니다.

curl -s https://get.docker.com/ | sudo sh

설치 방법은 여러개가 있겠지만 아래의 명령어로 손쉽게 설치 가능합니다.

docker version

위의 명령어로 도커가 설치완료되었는지 확인합니다.

2.도커 실행

docker run [OPTIONS] IMAGE:[version] [COMMAND]

-option

위와 같은 형식으로 도커를 실행할수 있다.

-실행

docker run ubuntu:20.04

위와 같이 실행하면, 우분투 20.04 이미지를 다운받아 실행하게 됩니다. 도커의 실행은 하나의 프로세스 실행과 같아서 위의 명령어로는 실행은 되지만 이외의 동작은 없고 바로 프로세스가 종료되게 됩니다.

docker run -it ubuntu:20.04

실행한 우분투 컨테이너 내부에서 터미널 입력이 가능해집니다.

docker run -d -p 3306:3306 \ 
 -e MYSQL_ALLOW_EMPTY_PASSWORD=true \ 
 --name mysql \ 
 mysql

mysql최신 버전의 이미지를 mysql이름을 지정후 다운 받은후, 3306(로컬):3306(컨테이너) 포트를 연결시켜주어 백그라운드에서 동작시켰습니다.

docker exec -it mysql mysql 
create database wp CHARACTER SET utf8; 
grant all privileges on wp.* to wp@'%' identified by 'wp'; 
flush privileges;

-exec명령어

docker run과는 달리, docker exec는 이미 실행중인 컨테이너에 접속할때 사용되는 명령어입니다. exec로 백그라운드에서 실행중인 mysql에 접속하여 데이터베이스를 생성해주었습니다.

3.도커 기본명령어

-ps: 실행중인 도커 컨테이너를 확인하는 명령어

docker ps
docker ps -a # 실행중지된 컨테이너까지 모두 확인가능

-stop: 도커 컨테이너 중지 명령어

docker stop [OPTIONS] CONTAINER [CONTAINER...]

컨테이너 ID or NAME으로 중지명령

-rm: 도커 컨테이너 삭제 명령어

docker rm [OPTIONS] CONTAINER [CONTAINER...]

-logs: 실행중인 컨테이너의 로그를 확인하는 명령어

docker logs [OPTIONS] CONTAINER

-images: 다운받은 이미지를 확인하는 명령어

docker images [OPTIONS] [REPOSITORY[:TAG]]

-pull: 도커 이미지를 다운받는 명령어

docker pull [OPTIONS] NAME[:TAG|@DIGEST]

-rmi: 도커 이미지 삭제 명령어

docker rmi [OPTIONS] IMAGE [IMAGE...]

4.도커 network

앞서 설명한 명령어중 --name을 통해 네이밍이 되어있는 컨테이너들끼리 통신을 위한 방식입니다.

웹서비스를 운영할때 80번 외부포트에서 request를 받아주면 내부의 로컬끼리는 포트번호를 통해 통신을 하는데 도커의 컨테이너 통신에서는 컨테이너를 생성할때 지어준 이름으로 통신을 하게 됩니다. 

-network create

docker network create [OPTIONS] NETWORK-NAME

-network connet

docker network connect [OPTIONS] NETWORK CONTAINER

네트워크 생성 -> 기존생성된 컨테이너 네트워크에 연결

위와 같은 과정을 거치면 네트워크에 연결한 컨테이너는 서로 통신을 할수 있는 준비가 됩니다.

ex)

docker run -d -p 8080:80 \ 
 --network=example \
 ...

ref. 인프런 강의. 초보를 위한 도커 안내서를 보고 참고하여 정리하였습니다.

1. 서버를 관리한다는것

• 어떠한 프로그램이 동작할때 잘돌고 있지만 뒤 즉, 서버단은 매우복잡한 논리의 집합으로 돌아가고 있는것
• 수많은 로직들중에 하나라도 잘못되어있을경우, 전체가 돌아가지 않는다
• 서버를 관리한다는것은 이많은 논리의 집합을 오류없이 잘돌아가도록 관리하는것
  • 하지만 너무 잦은 개발환경의 변화로 인해 리소스의 낭비가 심해졌다
  • 이를 해결하기위해 도커가 등장했다.

2. 서버관리 방식의 변화

• 전통적인 서버관리방식
  • user추가 -> system환경 -> 방화벽 -> ... -> proxy서버 -> 서버 실행
  • 매우 복잡한 여러 방식들을 하나하나 만들어 서버를 실행시켜야함
  • 이중 하나라도 문제가 생겼을때 전체적으로 오류가 발생함
• 도커의 등장으로 인해..
  • user컨테이너, chat 컨테이너...와 같이 여러 기능들을 하나의 컨테이너처럼 독립적으로 실행시킬수 있음
  • 하나의 오류가 생기더라도 독립적으로 실행되고 있기때문에 문제가 없고 매우 효율적으로 서버 동작
• 가상머신과 비교
  • 매우빠르다
  • 초기 환경 세팅을 일일이 할필요가 없다
  • 따라서 매우 효율적이다

3. 도커의 등장 배경

• 서버 실행 방법 문서화
  • 서버를 실행할때 설치할 과정이나 주의점을 문서화를 통해 후임자나 다른사람에게 공유
  • 이문서가 정확할지? 누락된 부분이 있어 그대로 실행안됨...과 같은 문제점이 있음
• 상태관리 도구 도입(chef, puppet, ansible...)
  • webserver, library등 문서로만 적혀있는것이 아닌 코드로 관리함으로써 환경을 공유하고 쉽게 설치 하게 개선
  • 각각의 서버, 여러 환경때문에 제대로 적용이 안되는 문제점이 있음
• 가상머신
  • 여러 기능등을 각각의 가상머신에 설치한뒤 이 가상머신을 관리할수 있는 서버에 띄어둠
  • 한서버에 여러개 설치가 가능하고, 현재의 상태를 저장할수 있는 엄청난 이점
  • 처음부터 다시 셋팅할대 어려움이 있음, 매우느림, 공유하기 어려운 문제점이 있음
• 도커의 등장!
  • 컨테이너: 격리된 환경에서 작동하는 프로세스
  • 하드웨어 가상화 기술보다 가벼움
  • 이미지 단위의 프로세스 실행 환경을 구성
  • 즉, 위의 여러 문제점을 모두 개선한 컨테이너 기술!

4. 도커의 장점

• 확장성/이식성
  • 도커가 설치되어 있다면 어디서든 컨테이너 실행 가능
  • 쉽게 개발서버를 만들수 있고 테스트서버 생성또한 간편함
• 표준성
  • 도커를 사용하지 않는 경우 여러 프레임워크로 만든 서비스들의 배포 방식이 매우 다양함
  • 컨테이너라는 표준으로 서버를 배포하므로 모든 서비스들의 배포 과정이 동일해짐
• 이미지
  • 컨테이너를 실행하기위한 하나의 압축 파일과 같음
  • 이미지에서 컨테이너를 생성하기 때문에 반드시 이미지를 만드는 과정 필요
  • Dockerfile을 이용하여 이미지를 만들고 처음부터 재현 가능
• 설정관리
  • 설정은 보통 환경변수로 제어
  • 하나의 컨테이너를 띄울때 환경변수를 같이 지정
• 자원관리
  • 컨테이너는 삭제 후 새로 만들면 모든 데이터가 초기화됨
  • 업로드 파일을 외부 스토리지와 링크하여 사용하거나 s3같은 별도의 저장소가 필요함

ref. 인프런 강의. 초보를 위한 도커 안내서를 보고 참고하여 정리하였습니다.