고민의 흔적

개요

지속적인 배포, 블루-그린 배포, 카나리아 배포 등과 같은 애플리케이션 배포 시나리오를 관리하기 위해 정기적으로 여러 배포를 사용합니다. 이 실습에서는 여러 이기종 배포가 사용되는 이러한 일반적인 시나리오를 수행할 수 있도록 컨테이너 확장 및 관리에 대한 실습을 제공합니다.

배포 소개

이기종 배포에는 일반적으로 특정 기술 또는 운영 요구 사항을 해결하기 위해 둘 이상의 별개의 인프라 환경 또는 지역을 연결하는 작업이 포함됩니다. 이기종 배포는 배포의 세부 사항에 따라 하이브리드, 멀티 클라우드 또는 퍼블릭-프라이빗이라고 합니다. 이 실습의 목적에 따라 이기종 배포에는 단일 클라우드 환경, 여러 퍼블릭 클라우드 환경(멀티 클라우드) 또는 온프레미스와 퍼블릭 클라우드 환경의 조합(하이브리드 또는 퍼블릭-프라이빗) 내의 지역에 걸친 배포가 포함됩니다.

단일 환경 또는 지역으로 제한된 배포에서는 다양한 비즈니스 및 기술 문제가 발생할 수 있습니다.

• 최대 리소스 : 모든 단일 환경, 특히 온프레미스 환경에서는 프로덕션 요구 사항을 충족하는 컴퓨팅, 네트워킹 및 스토리지 리소스가 없을 수 있습니다.
• 제한된 지리적 범위 : 단일 환경에 배포하려면 지리적으로 멀리 떨어져 있는 사람들이 하나의 배포에 액세스해야 합니다. 트래픽은 전 세계의 중앙 위치로 이동할 수 있습니다.
• 제한된 가용성 : 웹 규모의 트래픽 패턴은 애플리케이션이 내결함성과 탄력성을 유지하도록 요구합니다.
• 공급업체 종속 : 공급업체 수준 플랫폼 및 인프라 추상화로 인해 애플리케이션을 이식할 수 없습니다.
• 유연하지 않은 리소스 : 리소스가 특정 컴퓨팅, 스토리지 또는 네트워킹 오퍼링 세트로 제한될 수 있습니다.

이기종 배포는 이러한 문제를 해결하는 데 도움이 될 수 있지만 프로그래밍 방식의 결정론적 프로세스와 절차를 사용하여 설계해야 합니다. 일회성 또는 임시 배포 절차로 인해 배포 또는 프로세스가 취약해지고 장애를 견딜 수 없게 될 수 있습니다. 임시 프로세스는 데이터를 손실하거나 트래픽을 삭제할 수 있습니다. 좋은 배포 프로세스는 반복 가능해야 하며 프로비저닝, 구성 및 유지 관리를 위해 입증된 접근 방식을 사용해야 합니다. 이기종 배포에 대한 세 가지 일반적인 시나리오는 다중 클라우드 배포, 온프레미스 데이터 프론팅 및 CI/CD(지속적 통합/지속적 전달) 프로세스입니다.

1. 배포

gcloud container clusters create bootcamp --num-nodes 5 --scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"

5개의 노드가 있는 클러스터를 만듭니다.

kubectl explain deployment

deployment에 대한 설명을 보여주는 명령어입니다.

kubectl explain deployment --recursive

--recursive 옵션을 사용하면 모든 필드에 대한 doployment 내용을 확인할 수 있습니다.

deployments/auth.yaml구성 파일을 업데이트합니다.

spec:
  container:
	image: "kelseyhightower/auth:1.0.0"

"kelseyhightower/auth:2.0.0"을 "kelseyhightower/auth:1.0.0"으로 업데이트를 해줍니다.

kubectl create -f deployments/auth.yaml

kubectl create 인증 배포를 생성하기 위해 명령을 실행하면 배포 매니페스트의 데이터를 준수하는 하나의 포드가 생성됩니다. 이는 replicas필드에 지정된 수를 변경하여 Pod 수를 확장할 수 있음을 의미합니다.

kubectl get deployments

배포를 생성한 후에는 생성되었는지 확인할 수 있습니다.

kubectl get replicasets

배포가 생성되면 Kubernetes는 배포용 ReplicaSet을 생성합니다. 배포를 위해 ReplicaSet이 생성되었는지 확인할 수 있습니다.

kubectl get pods

마지막으로 배포의 일부로 생성된 파드를 볼 수 있습니다. ReplicaSet이 생성될 때 Kubernetes에 의해 단일 Pod가 생성됩니다.

kubectl create -f services/auth.yaml

이제 인증 배포를 위한 서비스를 만들 차례입니다. 위의 명령어를 사용해서 인증 서비스를 만듭니다.

kubectl create -f deployments/hello.yaml
kubectl create -f services/hello.yaml

hello Deployment를 만들고 expose 합니다.

kubectl create secret generic tls-certs --from-file tls/
kubectl create configmap nginx-frontend-conf --from-file=nginx/frontend.conf
kubectl create -f deployments/frontend.yaml
kubectl create -f services/frontend.yaml

frontend 배포를 만들고 노출합니다.

kubectl get services frontend

curl -ks https://<EXTERNAL-IP>

외부 IP에 curl 명령을 치면 Hello라고 잘 나오는 것을 확인하실 수 있습니다.

2. 확장

이제 배포가 생성되었으므로 확장할 수 있습니다. 

kubectl scale deployment hello --replicas=5

kubectl scale의 replicas 필드는 위의 명령어를 사용하여 쉽게 업데이트할 수 있습니다.

kubectl get pods | grep hello- | wc -l
kubectl scale deployment hello --replicas=3
kubectl get pods | grep hello- | wc -l

deployment가 업데이트되면 Kubernetes는 연결된 ReplicaSet을 자동으로 업데이트하고 새 Pod를 시작하여 총 Pod 수가 5가 되도록 한다. 이제 5개의 helloPod가 실행 중인지 확인합니다. 확인하는 명령어는 kubectl get pods | grep hello- | wc -l입니다. kubectl scale deployment hello --replicas=3은 애플리케이션의 replicas를 3으로 축소하는 명령어입니다.

롤링 업데이트

배포는 롤링 업데이트 메커니즘을 통해 이미지를 새 버전으로 업데이트하는 것을 지원합니다. Deployment가 새 버전으로 업데이트되면 새 ReplicaSet을 생성하고 이전 ReplicaSet의 복제본이 감소함에 따라 새 ReplicaSet의 복제본 수를 천천히 늘립니다.

deployments/auth.yaml구성 파일을 업데이트합니다.

spec:
  container:
	image: "kelseyhightower/auth:2.0.0"

"kelseyhightower/auth:1.0.0"을 "kelseyhightower/auth:2.0.0"으로 업데이트를 해줍니다.

편집기에서 저장하면 업데이트된 배포가 클러스터에 저장되고 Kubernetes가 롤링 업데이트를 시작합니다.

kubectl get replicaset
kubectl rollout history deployment/hello

실행 중인 롤아웃에서 문제가 감지되면 일시 중지하여 업데이트를 중지합니다.

kubectl rollout pause deployment/hello
kubectl rollout status deployment/hello
kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

1번째 명령어는 중지시키는 명령어입니다. 2번째 명령어는 deployment의 상태를 확인하는 명령어입니다.

3번째 명령어는 Pod에서 확인하기 위한 명령어입니다.

kubectl rollout resume deployment/hello
kubectl rollout status deployment/hello

롤아웃이 일시 중지되어 일부 포드는 새 버전이고 일부 포드는 이전 버전입니다. resume명령 을 사용하여 롤아웃을 계속할 수 있습니다.

status롤아웃이 완료되면 위의 status 명령어를 실행할 때 "hello" 성공적으로 롤아웃이 되었습니다라고 출력되어야 합니다.

kubectl rollout undo deployment/hello
kubectl rollout history deployment/hello
kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

새 버전에서 버그가 감지되었다고 가정합니다. 새 버전에는 문제가 있는 것으로 추정되므로 새 Pod에 연결된 모든 사용자는 이러한 문제를 겪을 것입니다.

조사한 다음 제대로 수정된 버전을 릴리스할 수 있도록 이전 버전으로 롤백하고 싶을 것입니다.

다음 명령을 사용 rollout하여 이전 버전으로 롤백합니다.

카나리아 배포

사용자의 하위 집합을 사용하여 프로덕션에서 새 배포를 테스트하려는 경우 카나리아 배포를 사용합니다. Canary 배포를 사용하면 소규모 사용자 하위 집합에 대한 변경 사항을 릴리스하여 새 릴리스와 관련된 위험을 완화할 수 있습니다.

카나리아 배포는 새 버전이 포함된 별도의 배포와 정상적인 안정적인 배포와 카나리아 배포를 모두 대상으로 하는 서비스로 구성됩니다.

kubectl create -f deployments/hello-canary.yaml
kubectl get deployments

Canary 배포가 생성된 후에는 hello 하고 hello-canary의 두 개의 배포가 있어야 한다.

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

hello요청에 의해 제공되는 버전을 확인할 수 있습니다. 이것을 여러 번 실행하면 일부 요청이 hello 1.0.0에서 제공되고 작은 하위 집합(1/4 = 25%)이 2.0.0에서 제공되는 것을 볼 수 있습니다.

블루 - 그린 배포

롤링 업데이트는 오버헤드를 최소화하고 성능에 미치는 영향을 최소화하며 가동 중지 시간을 최소화하면서 애플리케이션을 천천히 배포할 수 있기 때문에 이상적입니다. 새 버전이 완전히 배포된 후에만 해당 새 버전을 가리키도록 로드 밸런서를 수정하는 것이 유리한 경우가 있습니다. 이 경우 블루-그린 배포가 올바른 방법입니다.

Kubernetes는 두 개의 개별 배포를 생성하여 이를 달성합니다. 하나는 이전 "파란색" 버전용이고 다른 하나는 새 "녹색" 버전용입니다. hello"파란색" 버전에 대해 기존 배포를 사용합니다. 배포는 라우터 역할을 하는 서비스를 통해 액세스 됩니다.새로운 "그린" 버전이 실행되고 나면 서비스를 업데이트하여 해당 버전을 사용하도록 전환합니다.

블루-그린 배포의 주요 단점은 애플리케이션을 호스팅 하는 데 필요한 클러스터에 최소 2배의 리소스가 필요하다는 것입니다. 한 번에 두 버전의 애플리케이션을 모두 배포하기 전에 클러스터에 충분한 리소스가 있는지 확인하십시오.

kubectl apply -f services/hello-blue.yaml

먼저 서비스를 업데이트합니다.

kubectl create -f deployments/hello-green.yaml
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
kubectl apply -f services/hello-green.yaml
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

녹색 배포가 있고 제대로 시작되면 현재 버전 1.0.0이 여전히 사용 중인지 확인합니다. 이제 새 버전을 가리키도록 서비스를 업데이트합니다. 서비스가 업데이트되면 "그린" 배포가 즉시 사용됩니다. 이제 새 버전이 항상 사용 중인지 확인할 수 있습니다.

kubectl apply -f services/hello-blue.yaml
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

필요한 경우 동일한 방식으로 이전 버전으로 롤백할 수 있습니다. "파란색" 배포가 계속 실행되는 동안 서비스를 이전 버전으로 다시 업데이트하기만 하면 됩니다. 서비스를 업데이트하면 롤백이 성공한 것입니다. 다시 한 번 올바른 버전이 사용 중인지 확인합니다.

개요

• Kubernetes Engine을 사용하여 완전한 Kubernetes 클러스터를 프로비저닝 합니다.
• 를 사용하여 Docker 컨테이너를 배포하고 관리 kubectl합니다.
• Kubernetes의 배포 및 서비스를 사용하여 애플리케이션을 마이크로 서비스로 나눕니다.

GitHub에서 샘플 코드를 가져와서 실습을 하셔야 됩니다.

1. Pods

kubectl create deployment nginx --image=nginx:1.10.0

Kubernetes는 deployment를 만들었습니다. deployment에 대한 자세한 내용은 나중에 설명한다고 합니다. 지금은 배포가 실행되는 노드에 오류가 발생하더라도 배포가 포드를 계속 실행 상태로 유지한다는 점만 알면 된다.

kubectl get pods

위의 명령어를 사용하여 현재 실행 중인 nginx 컨테이너를 볼 수 있다.

kubectl expose deployment nginx --port 80 --type LoadBalancer

Kubernetes는 공개 IP 주소가 연결된 외부 로드 밸런서를 생성했다. 해당 공용 IP 주소에 도달한 모든 클라이언트는 서비스 뒤의 포트로 라우팅 된다.

kubectl get services

Kubernetes의 현재 서비스 중인 목록을 볼 수 있다.

curl http://<External IP>:80

External IP를 이용하여 curl 명령어를 치면 Welcome to nginx 가 나오는 것을 확인하실 수 있습니다.

Kubernetes의 핵심은 Pod가 있다. Pod는 하나 이상의 컨테이너 컬렉션을 나타내고 보유한다. 일반적으로 서로에 대한 종속성이 강한 여러 컨테이너가 있는 경우 컨테이너를 단일 Pod 안에 패키징 한다. Pod에는 Volumes 도 있다.볼륨은 Pod가 살아있는 동안 지속되는 데이터 디스크이며 해당 포드의 컨테이너에서 사용할 수 있습니다. Pod는 콘텐츠에 대한 공유 네임스페이스를 제공합니다. 즉, 예제 Pod 내부의 두 컨테이너는 서로 통신할 수 있으며 연결된 볼륨도 공유할 수 있습니다. Pod는 또한 네트워크 네임스페이스를 공유한다. 이는 Pod 당 하나의 IP 주소가 있음을 의미합니다.

cat pods/monolith.yaml

위의 명령어는 모놀리스 포드 구성 파일을 확인하는 명령어이다.

• Pod는 하나의 컨테이너(모놀리스)로 구성됩니다.
• 컨테이너가 시작될 때 몇 가지 인수를 컨테이너에 전달합니다.

kubectl create -f pods/monolith.yaml

모놀리스 Pod를 만드는 명령어입니다.

모놀리스 컨테이너 이미지를 실행하려면 먼저 Docker Hub에서 가져와야 합니다.

kubectl describe pods monolith

kubectl describe 명령어를 사용하면 모노리스 Pod IP 주소 및 이벤트 로그를 포함하여 모놀리스 Pod에 대한 자세한 정보를 얻을 수 있다.

kubectl port-forward monolith 10080:80

기본적으로 Pod에는 사설 IP 주소가 할당되며 클러스터 외부에서 연결할 수 없습니다. kubectl port-forward 명령어를 사용하여 로컬 포트를 모놀리스 포드 내부의 포트에 매핑합니다.

curl http://127.0.0.1:10080

새로운 터미널을 열어서 curl 명령어를 치면 Hello라고 나오는 것을 확인하실 수 있습니다.

curl http://127.0.0.1:10080/secure

curl명령을 사용하여 보안 엔드포인트에 도달했을 때 인증 실패라고 나오는 것을 확인하실 수 있습니다.

curl -u user http://127.0.0.1:10080/login

로그인을 해서 JWT 토큰을 발급받습니다.

TOKEN=$(curl http://127.0.0.1:10080/login -u user|jq -r '.token')

Cloud Shell은 긴 문자열 복사를 잘 처리하지 못하므로 토큰에 대한 환경 변수를 만듭니다.

curl -H "Authorization: Bearer $TOKEN" http://127.0.0.1:10080/secure

다시 발급받은 토큰을 이용해서 접근을 하면 Hello 메시지가 정상 출력되는 것을 확인하실 수 있습니다.

kubectl logs monolith

위의 명령어는 log를 확인하는 명령어입니다.

kubectl logs -f monolith

-f는 실시간으로 발생하는 로그를 확인할 수 있는 명령어입니다.

kubectl exec monolith --stdin --tty -c monolith -- /bin/sh

위의 명령어는 Monolith Pod 내에서 대화형 셸을 실행합니다. 컨테이너 내에서 문제를 해결하려는 경우에 유용하게 사용할 수 있다.

ping -c 3 google.com

모놀리스 컨테이너에 셸이 있으면 ping명령을 사용하여 외부 연결을 테스트할 수 있습니다.

2. Services

포드는 영구적이지 않다. 여러 가지 이유로 중지되거나 다시 시작될 수 있으며 이로 인해 문제가 발생한다. Pod 집합과 다시 통신하려는 경우 다시 시작할 때 다른 IP 주소를 가질 수 있습니다. 이때 필요한 것이 서비스입니다. 서비스는 Pod에 안정적인 엔드포인트를 제공합니다.

서비스는 레이블을 사용하여 작동하는 Pod를 결정합니다. Pod에 올바른 레이블이 있으면 자동으로 선택되어 서비스에 노출된다.

서비스가 Pod에 제공하는 액세스 수준은 서비스 유형에 따라 다르다. 이에는 세 가지 유형이 있습니다.

• ClusterIP(내부) 기본 유형은 이 서비스가 클러스터 내부에서만 볼 수 있음을 의미합니다.
• NodePort클러스터의 각 노드에 외부에서 액세스 할 수 있는 IP를 제공하고
• LoadBalancer서비스에서 서비스 내의 노드로 트래픽을 전달하는 클라우드 공급자의 로드 밸런서를 추가합니다.

cat pods/secure-monolith.yaml

서비스를 생성하기 전에 먼저 https 트래픽을 처리할 수 있는 보안 포드를 생성한다.

kubectl create secret generic tls-certs --from-file tls/
kubectl create configmap nginx-proxy-conf --from-file nginx/proxy.conf
kubectl create -f pods/secure-monolith.yaml

보안 모노리스 Pod와 해당 구성 데이터를 작성하는 명령어입니다.

이제 보안 Pod가 생성되었으므로 보안 모놀리스 Pod를 외부에 노출해야 된다. 외부에 노출하려면 Kubernetes 서비스를 생성해야 된다.

• app: monolith 및 레이블이 있는 모든 포드를 자동으로 찾고 노출하는 데 사용되게  하는 secure: enabled이 있다.
• 이제 포트 31000번에서 nginx포트 443으로 외부 트래픽을 전달해야 되므로 노드 포트를 expose 해야 한다.

kubectl create -f services/monolith.yaml

모놀리식 서비스를 만드는 명령어이다.

gcloud compute firewall-rules create allow-monolith-nodeport --allow=tcp:31000

위의 명령어는 노출된 노드 포트에서 모놀리식 서비스에 대한 트래픽을 허용하는 명령어입니다.

gcloud compute instances list

리스트에 대한 정보를 볼 수 있는 명령어입니다. 노드 중 하나에 대한 외부 IP 주소를 가져옵니다.

curl -k https://<EXTERNAL_IP>:31000

curl 명령어를 치면 실패하는 것을 확인하실 수 있습니다.

현재 모놀리스 서비스에는 endpoint가 없습니다. 이와 같은 문제를 해결하는 한 가지 방법은 kubectl get pods레이블 쿼리와 함께 명령어를 사용하는 것입니다.

kubectl label pods secure-monolith 'secure=enabled'
kubectl get pods secure-monolith --show-labels

 Pod에 kubectl label에 누락된 레이블 secure=enabled 추가합니다.

kubectl describe services monolith | grep Endpoints

올바르게 레이블이 지정되었으므로 모놀리스 서비스에서 엔드포인트 목록을 확인하면 올바르게 나오는 것을 확인할 수 있다.

curl -k https://<EXTERNAL_IP>:31000

curl 명령어를 실행시키면 Hello라고 잘 나오는 것을 확인하실 수 있습니다.

3. Deployment

Deployment는 실행 중인 Pod 수가 사용자가 지정한 원하는 Pod 수와 동일하도록 만드는 방법입니다.

Deployment의 주요 이점은 Pod 관리의 낮은 수준 세부 정보를 추상화한다는 것입니다. Deployment는 복제본 세트를 사용하여 Pod 시작 및 중지를 관리합니다. Pod를 업데이트하거나 확장해야 하는 경우나 어떤 이유로 인해 중단된 경우, 다시 시작해야 하는 경우 Deployment에서 처리합니다.

Pod는 생성된 노드의 수명과 연결됩니다. 위의 예에서 Node3이 다운되었습니다(Pod와 함께 사용). 새 Pod를 수동으로 생성하고 이에 대한 노드를 찾는 대신 Deployment에서 새 Pod를 생성하고 Node 2에서 시작했습니다.

이제 Pod 및 서비스에 대해 배운 모든 것을 결합하여 Deployment를 사용하여 모놀리식 애플리케이션을 더 작은 서비스로 분할해봅시다.

모놀리스 앱을 세 개의 개별 조각으로 나눕니다.

• auth - 인증된 사용자에 대한 JWT 토큰을 생성합니다.
• hello - 인증된 사용자를 환영합니다.
• frontend - auth 및 hello 서비스로 트래픽을 라우팅 합니다.

각 서비스에 대해 하나씩 배포를 만들 준비가 되었습니다. 그런 다음 auth 및 hello 배포를 위한 내부 서비스와 frontend 배포를 위한 외부 서비스를 정의합니다. 완료되면 Monolith와 마찬가지로 마이크로 서비스와 상호 작용할 수 있습니다. 이제 각 부분을 독립적으로 확장하고 배포할 수 있습니다.

cat deployments/auth.yaml

Replicas 필드에 지정된 수를 변경하여 Pod 수를 확장할 수 있습니다.

kubectl create -f deployments/auth.yaml

deployments 개체를 만드는 명령어입니다.

kubectl create -f services/auth.yaml

인증 deployment를 위한 서비스를 만드는 명령어입니다.

kubectl create -f deployments/hello.yaml
kubectl create -f services/hello.yaml

hello deployment와 서비스를 만들고 expose 합니다.

kubectl create configmap nginx-frontend-conf --from-file=nginx/frontend.conf
kubectl create -f deployments/frontend.yaml
kubectl create -f services/frontend.yaml

frontend deployment를 만들고 expose 합니다.

kubectl get services frontend

위의 명령어를 이용해 외부 IP 주소를 확인합니다.

curl -k https://<EXTERNAL-IP>

curl 명령어로 EXTERNAL-IP로 요청을 보내면 Hello라는 메시지가 잘 나오는 것을 확인하실 수 있습니다.

쿠버네티스 입문반 Introduction to Docker

첫 수업으로 Introduction to Docker 강의를 들었습니다. 구글 클라우드 환경에서 터미널에 접속해 docker를 실행하고 실습하는 시간이 되었습니다. docker기본을 배우고 듣는 수업이라 어려운 수업은 아니였습니다. 강의가 영어로 되어있어 살짝 힘든 것 말고는 좋은 학습이 될 것 같습니다. 혹시 몰라 구글에서 사용하는 아이디는 모자이크 처리하였습니다.

구글 클라우드 쉘에 접속한 모습입니다. 여기서 쿠버네티스 실습을 진행합니다.

docker run hello-world

위의 사진을 잘 보시면 Unable to find image를 보실 수 있습니다. docker 데몬은 hello-world 이미지를 검색했지만 로컬에서 이미지를 찾지 못해서 Docker Hub라는 공개 레지스트리에서 이미지를 가져와서 해당 이미지에서 컨테이너를 생성하고 컨테이너를 실행했습니다.

docker images

docker images 명령어입니다. 이 스크린 샷은 못 찍었습니다. 이미지 목록을 확인하는 명령어입니다.

docker run hello-world

정상적으로 실행되었습니다. Hello from Docker !

docker ps

docker ps 명령어입니다. 실행 중인 컨테이너가 없습니다. 이전에 실행한 hello-world 컨테이너가 이미 종료되었습니다. 

docker ps -a

종료된 컨테이너를 포함하여 모든 컨테이너를 보려면 docker ps에서 - a 옵션만 추가시켜주면 됩니다.

mkdir test
cd test

test 디렉터리를 만들고 test 디렉터리에 들어갑니다. 

cat > Dockerfile <<EOF
# 공식 Node 런타임을 부모 이미지로 사용 
FROM node:lts
# 컨테이너의 작업 디렉터리를 /app으로 설정 
WORKDIR /app
# 현재 디렉터리 내용을 /app으로 설정
ADD . /app
# 컨테이너의 포트 80을 외부에서 사용할 수 있도록 설정.
EXPOSE 80
# 컨테이너가 실행될 때 node를 사용하여 app.js를 실행합니다. 
CMD ["node", "app.js"]
EOF

dockerfile을 만드는 방법에 대한 설명입니다. 간단하게 실습하는 것이라 명령어에 잘 모르실 경우 제 블로그 참고 바랍니다.

https://lusida-coding.tistory.com/35?category=1031465 

cat > app.js <<EOF
const http = require('http');
const hostname = '0.0.0.0';
const port = 80;
const server = http.createServer((req, res) => {
    res.statusCode = 200;
    res.setHeader('Content-Type', 'text/plain');
    res.end('Hello World\n');
});
server.listen(port, hostname, () => {
    console.log('Server running at http://%s:%s/', hostname, port);
});
process.on('SIGINT', function() {
    console.log('Caught interrupt signal and will exit');
    process.exit();
});
EOF

노드 애플리케이션 파일을 만듭니다. 포트 80에서 수신 대기하고 Hello World를 출력하는 간단한 HTTP 서버입니다.

docker build -t node-app:0.1 .

이미지를 빌드합니다. "."은 현재 디렉터리를 의미하므로 Dockerfile이 있는 디렉토리 내에서 이 명령어를 실행해야 합니다.

node은 기본 이미지이며 node-app빌드한 이미지입니다. node먼저 제거하지 않고는 node-app을 제거할 수 없습니다. 이미지의 크기는 VM에 비해 상대적으로 작습니다.

docker run -p 4000:80 --name my-app node-app:0.1

방금 빌드한 이미지를 기반으로 컨테이너를 실행합니다. 현재 터미널에서 실행되는 것을 확인하실 수 있습니다.

curl http://localhost:4000

--name은 원하는 경우 컨테이너의 이름을 지정할 수 있습니다.호스트 의 -p포트 4000을 컨테이너의 포트 80에 매핑하도록 명령어를 작성했다. 이제 http://localhost:4000. 포트 매핑이 없으면 localhost의 컨테이너에 연결할 수 없습니다. 다른 터미널을 열고 서버를 테스트합니다. Hello World가 정상적으로 출력되는 것을 확인하실 수 있습니다.

docker stop my-app && docker rm my-app

컨테이너를 중지하고 컨테이너를 지우는 명령어입니다.

docker run -p 4000:80 --name my-app -d node-app:0.1

컨테이너를 백그라운드에서 실행하려면(터미널 세션에 연결되지 않음) -d옵션을 지정해야 합니다.

docker logs my-app

컨테이너의 로그를 확인하는 명령어입니다.

docker logs -f [container_id]

 컨테이너가 실행될 때 로그의 출력을 실시간으로 확인하려면 -f옵션을 사용하면 됩니다.

docker build -t node-app:0.2 .

app.js파일에서 Hello World를 Hello Cloud로 수정 후 node-app:0.2로 빌드를 진행하였습니다.

2단계에서 기존 캐시 계층을 사용하고 있음을 알 수 있습니다. 3단계부터 에서 변경했기 때문에 레이어가 수정됩니다.

docker run -p 8080:80 --name my-app-2 -d node-app:0.2
curl http://localhost:8080
curl http://localhost:4000

새 이미지 버전으로 다른 컨테이너를 실행합니다. 호스트 포트 4000은 이미 사용 중이기 때문에 사용할 수 없습니다. 컨테이너를 실행 후 curl로 8080과 4000에 접속 테스트를 진행하였습니다. 8080에는 모자이크로 잘리긴 했으나 Hello to Cloud가 출력되었고 4000에는 수정하기 전인 Hello World가 출력되었습니다.

docker exec -it [container_id] bash

실행 중인 컨테이너 내에서 Bash 세션을 시작할 때는 명령어 마지막에 bash라고 지정해주면 됩니다. docker exec -it를 사용하면 pseudo-tty를 할당하고 표준 입력을 열린 상태로 유지하여 컨테이너와 상호 작용할 수 있습니다. bash는 Dockerfile에 WORKDIR지정된 디렉터리(/app)에서 실행되었습니다.

docker inspect [container_id]

Docker inspect를 사용하여 Docker에서 컨테이너의 메타데이터를 확인할 수 있습니다.

docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' [container_id]

docker tag node-app:0.2 gcr.io/[project-id]/node-app:0.2

도커를 푸시를 해주려면 컨테이너에 태그가 붙어있어야 합니다. 제 개인 도커 레파지토리에 푸시를 하려면 제 도커 레파지토리 이름 태그를  붙여줘야 합니다.

docker push gcr.io/[project-id]/node-app:0.2

도커를 gcr에 푸시하는 명령어입니다.