✔️ 실습에 앞서 이번 실습에서는 Jenkins와 함께 kubernetes 엔진에 지속적인 전달 파이프라인을 설정하는 방법을 배울 것이다. Jenkins는 공유 저장소에 코드를 자주 통합하는 개발자들이 사용하는 자동 서버이다. 실습을 통해 구축하는 솔루션은 다음과 같다. ✔️ 실습 목표 Kubernetes 엔진 클러스터에 Jenkins 어플리케이션 프로비저닝 Helm Package Manager를 통해 Jenkins 어플리케이션 설정하기 Jenkins 어플리케이션의 기능 학습 Jenkins 파이프라인 생성 및 연습 ✔️ Jenkins란 ? (간단하게) Jenkins는 빌드, 테스트 및 배포 파이프라인을 유연하게 조정할 수 있는 오픈소스 자동화 서버이다. Jenkins는 개발자들이 지속적인 제공으로 인해 ..

✔️ Rolling update Deployments는 Rolling Update 메커니즘을 통해 이미지를 새 버전으로 업데이트할 수 있다. Deployment가 새 버전으로 업데이트될 때, 새 ReplicaSet을 생성하고 이전 ReplicaSet의 복제본 수를 줄이면서 새 ReplicaSet의 복제본 수를 천천히 늘린다. ✔️ Trigger a rolling update Deployment를 업데이트하려면 다음을 실행한다. kubectl edit deployment hello Deployment의 컨테이너의 섹션의 이미지를 변경한다. ... containers: image: kelseyhightower/hello:2.0.0 ... 한번 에디터에서 저장하면 업데이트된 Deployment가 Cluster..

✔️ 실습에 앞서.. 실습 목표 kubectl tool 사용 연습 deployment yaml 파일 작성하기 deployments 실행, 업데이트, 스케일 조정하기 depolyments 및 deployment style 업데이트 연습하기 ✔️ 초기 설정 Set zone 로컬 영역을 us-central1-a로 대체해 작동중인 Google Cloud zone을 설정한다. gcloud config set compute/zone us-central1-a Get sample code for this lab 컨테이너 및 deployments를 만들고 실행하기 위한 샘플 코드 가져오기 gsutil -m cp -r gs://spls/gsp053/orchestrate-with-kubernetes . cd orchestr..

앞선 실습으로 컨테이너 구축 및 실행에 대해 배웠으니 몇가지 디버깅 실무에 대해 실습해보자 ! ✔️ Debug docker logs [container_id]를 사용하여 컨테이너 로그를 볼 수 있다. 컨테이너가 실행 중일 때 로그 출력을 추적하려면 -f 옵션을 사용한다. docker logs -f [container_id] 실행 중인 컨테이너 내에서 대화형 Bash 세션을 시작할 수 있다. docker exec을 사용하여 이 작업을 수행할 수 있다. 다른 터미널을 열고 다음 명령을 입력해보자 docker exec -it [container_id] bash -it 플래그를 사용하면 pseudo-tty를 할당하고 stdin을 열린 상태로 유지하여 컨테이너와 상호 작용할 수 있다. bash가 Docker 파일..

✔️ 실습에 앞서 실습 목표 도커 컨테이너의 빌드, 실행 및 디버깅 방법 도커 이미지를 Google 컨테이너 레지스트리에 푸시하는 방법 도커 이미지를 Google 컨테이너 레지스트리에서 가져오는 방법 ✔️ Hello World docker run hello-world 이 간단한 컨테이너는 Hello from Docker! 를 출력한다. 명령어는 간단하지만 실행한 스텝의 수가 출력되어 있다. 도커 데몬은 hello-world 이미지를 검색했지만 로컬에서 이미지를 찾지 못하고 Docker Hub라는 Public Registry에서 이미지를 꺼내 해당 이미지에서 컨테이너를 만들고 실행했다. 다음 명령을 실행해 도커 허브에서 가져온 컨테이너 이미지를 확인한다. docker images 다음 내용은 도커 허브의 ..

이번에는 Kubernetes Service에 대해 실습해보자 ✔️ Service 한번 생성된 Pod는 영속적으로 존재하지 않을 수 있다. 동작 실패나 준비 상태 점검 등 여러 가지 이유로 인해 중단되거나 시작될 수 있으며 이로 인해 다음과 같은 문제가 발생한다. Pod를 재가동하면 이전과는 다른 IP 주소를 가질텐데 그렇다면 Pods의 set와 통신하려면 어떻게 해야할까? 이것이 서비스가 필요한 이유이다. 서비스는 Pods에 안정적인 Endpoint를 제공한다. Service는 labels을 사용해 어떤 Pods가 동작 중인지를 확인한다. Pods에 올바른 라벨이 붙어있는 경우는 service에 의해 자동적으로 인식되어 공개된다. 서비스가 일련의 Pod에 제공하는 액세스 레벨은 서비스의 타입에 달려있다...