[쿠어클#17] Application 개발자가 꼭 알아야 하는 Pod 기능들

이번 섹션에서는 Application 개발자가 꼭 알아야 하는 Pod 기능들이라는 주제로 여러 얘기 들을 해볼 건데요. 왜 개발자가 꼭 알아야 되냐면, 이번에 배우는 Pod의 기능들은 개발 로직이 받쳐주지 못하면, 써먹을 수 없는 기능들 이라서 그래요. 그래서 내 App이 쿠버네티스 환경 배포된다고 했을 때, 개발자 입장에서는 그 로직들을 잘 구현해 줘야 하고, 데브옵스 엔지니어 입장에서는 개발자에게 이런 로직들이 꼭 필요하다고 잘 얘기할 수 있어야 됩니다. 그럼 블로그를 시작해 볼께요.Application 개발자가 꼭 알아야 하는 Pod 기능들아래 그림을 보면, 워커노드 위에 [Pod가 생성]되는 과정에서 특정 노드(nodeSelector)를 지정 할 수가 있었고요. 이 워커노드에 리소스(resource)는 내 Pod에서 지정된 리소스보다 많이 있어야 겠죠. 그럼 DockerHub에서 이미지(image)를 가져와서 컨테이너와 App이 만들어 집니다. 이제 다음으로 [Pod가 기동하고 운영]되는 과정이 있는데, 여기서부터 컨테이너 안에 Application 개발이랑 관련된 내용들이 시작 됩니다.이제 여기서 이전에 배웠던 내용을 얘기해 볼게요.Probe를 설정하면 kubelet이, App에 헬스 체크 API를 날려주기 때문에 App에는 이 API들에 마춰서 Health를 체크를 해주는 로직이 필요 했고요. Comfigmap을 통해서 환경 변수를 줄 수 있었고, Application에서는 파라미터를 받아서 처리를 해주는 설정이 있어야 됐어요.그리고 또 민감하게 다뤄야 하는 설정 파일의 경우, Secret을 통해 컨테이너로 마운팅 할 수 있었고, App에서 이 파일에 접근하는 로직을 통해서 데이터를 읽을 수가 있어요.그리고 파일을 저장하고, 영구적으로 보관해야 되는 경우, PV를 통해서 워커노드에 넣을 수 있는데 이것도 개발 로직과 관련된 부분이라고 볼 수 있겠고요. 여기까지는 Sprint1에서 배웠던 내용 이였고. 워밍업 이였습니다. 😀이제부터가 이번 섹션에서 배울 내용들을 설명드릴 건데, 잘 들어 주시길 바랄께요.위 그림을 보시면, 수집 서버 입장에서 모든 Pod의 정보를 조회해 볼 목적으로 API를 날리는 상황이라고 해볼게요. 근데 Service에서는 pod로 트래픽을 랜덤하게 보내주기 때문에, 트래픽을 여러번 시도해야지 모든 Pod를 식별 할 수 있고. 이런 구조는 많은 네트워크 트래픽을 유발 시키기 때문에 좋지 않은 구조입니다.기존 VM 환경에서는 내가 배포할 App에 대해서 고정 IP가 정해져 있었고, 이 IP들을 모두 수집서버에 Config로 등록해서 딱 필요한 만큼의 조회 트래픽을 날렸었거든요. 근데 Pod는 IP가 자동 생성 되기도 하지만, Pod가 재생성 됐을 때 이 IP가 변경되기 때문에 쿠버네티스 환경에서 수집서버는 내가 정보를 조회 해야할 Pod들 한테 트래픽을 보내기가 힘들어 졌습니다.그럼 쿠버네티스 환경에서는 이런 상황을 어떤 구조로 바꿔서 해결해야 되냐면, Pod 스스로가 자신의 Pod 정보를 수집 서버에 전송해 주는 구성으로 만들어야 되요. 그리고 이러기 위해서 App에서 내 Pod 정보를 조회하는 로직이 필요한 거고요. 그 로직에는 이렇게 3가지 방식이 있는데, 이 방법들에 대한 차이와 사용법을 강의 수업에서 설명 드려요.이렇게 마이크로 서비스 아키텍쳐에서 전체 네트워크 트래픽을 줄이기 위해서 수집서버가 주기적으로 Pod 상태를 조회 하는게 아닌 각 Application들이 자신의 상태가 변경이 될 때마다 수집 서버로 API를 전송하는 방법을 쓰고요. 이외에도 Service를 통해서 특정 Pod에 호출이 된 다음에, 이후에는 이 두 Pod 끼리만 서로 양방향 통신을 해야 되는 경우 있습니다. 대표적으로 P2P 통신이고요. 우리가 메세지 관련된 어플리케이션을 만들 때, 그 통신 로직에 내 IP 주소를 넣어야 되요. 시스템 성능적인 면이나, 마찬가지로 전체 네트워크 트래픽을 줄이는 데 유리해요. 그래서 이렇게 개발 입장에서도 내 Pod의 IP 정보가 필요한 상황은 많다라는 말씀을 드리고 싶습니다. 이제 다음으로 Pod가 종료되는 상황에 대해서 얘기를 해볼께요.이건 정말 이전에 배웠던 probe 만큼이나 꼭 필요하고 중요한 내용이에요.통상 Applicaiton이 중단되는 경우는 장애가 발생하거나, 업그레이드, 혹은 시스템 점검이 있어서, 공지를 하고 내리기도 해요. 그리고 주로 새벽에 작업을 하기 때문에 이때 App을 종료시키다가 에러가 좀 나도 딱히 문제라고 생각하지 않습니다. 시스템을 내린 이후에 로그를 볼 생각 자체도 잘 안하고요. 그래서 지금까지 시스템 종료에 대해서 덜 중요하게 생각을 했을 수 있는데, 쿠버네티스 환경에서는 업그레이드나 스케일링들이 운영중도 빈번하게 일어나기 때문에 이런 상황에도 App 종료에 대한 로그를 계속 지켜볼게 아니라면, 이젠 App이 안전하게 종료되도록 만드는 부분이 매우 중요해 졌습니다.그리고 쿠버네티스 또한 App 종료에 대해서 지원해 주는 기능들이 있는데, 이 기능들에 대해서 간략하게 설명 드릴께요. Pod 삭제 명령을 받으면 kubelet은 App한테 종료 신호를 보내고요. App이 스스로 종료될 때까지 기다려요. 근데 어느 정도 시간이 지나도 App이 종료되지 않으면 강제로 Pod를 삭제 시켜 버리고요. 그래서 App에서는종료신호를 받았을 때, 현재 실행중인 App들을 잘 정리하는 로직을 만들어 놔야 합니다. App이 어떤 정리를 해야 되는 지에 대한 부분은 강의에서 자세히 말씀을 드릴 거고요.그리고 또 App은 종료 신호와는 별개로 내부적으로 메모리 릭이 나거나 해서 장애가 발생하고, 종료 될 수도 있거든요. 이럴 때 쿠버네티스가 알아서 컨테이너를 리스타트 시켜주기 때문에 걱정할 필요는 없지만, 그래도 한번씩 이전 컨테이너가 왜 재시작 됐는지에 대한 사유는 조회를 해봐야 되요.그래서 kubectl로 이전 컨테이너의 상태를 확인하는 방법들을 알려드릴 거고요. 또 App이 종료될 때 특정 파일에 에러에 대한 사유를 저장해 놓으면, Pod에는 이걸 kubectl로 볼 수 있게 해주는 기능도 있습니다.그리고 마지막으로 이렇게 Pod의 생성과 운영, 그리고 종료에 따라 Pod와 컨테이너 상태에 대해서 얘기를 해볼께요.Pod의 상태는 Phase라는 속성에 있고요. 이렇게 각각의 진행에 따라 그 값들이 달라져요.그리고 Pod 종료시에 Succeded와 failed이 있는 걸 보면, 쿠버네티스는 종료에 대해서 성공적인 종료와, 실패적인 종료를 구분해 놨다는 게 느껴지시죠? 그리고 Pod에 상태가 있지만, 컨테이너에도 별도로 상태가 또 존재합니다.containerStatuses라는 속성이고요. 이건 좀 단순해 보일 수 있는데, 여기에 이렇게 세부적인 Reason이 또 있어요.여기 CrashLoopBackOff는 Pod가 재대로 기동이 안될 때 대시보드에서 자주 볼 수 있는데, 실제 Pod는 Pending이고, 컨테이너는 waiting상태에서 이 reason 속성을 화면에 보여줬던 거죠. 그리고 종료에 있어서는 두 가지 Completed와 Error가 있습니다. 일반적으로 컨테이너가 정상 종료되면 Completed고, Pod도 Succeeded로 끝나는데, 한 Pod에는 컨테이너는 두 개 이상 있을 수 있기 때문에, 이때는 컨테이너 하나라도 Error가 있으면 Pod는 Failed 상태가 끝나게 되요. 그래서 다시 Pod 종료에 대한 상태를 정리하면,SIGTERM을 받은 App이 정상적으로 자원을 정리하고 스스로 종료가 되면 컨테이너의 상태가 Completed고 Pod도 Succeeded로 끝나지만, 스스로 정리를 다 못하고, 강제 삭제가 됐을 때는 컨테이너 상태는 Error고 Pod의 상태는 Failed로 끝나는 거에요.그럼 이번 블로그는 여기까지고요, 해당 강의에서는 아래 내용들에 대해서 더 다룹니다 😀[쿠버네티스 어나더 클래스] : https://inf.run/3oKqK내 Pod 정보를 API로 노출시키기 내 Application을 안정적으로 종료하기ps. 한번도 좋아요♡를 안 준 사람은 있어도, 한번만 좋아요♡를 준 사람은 없다. 당신은 어떤 사람인가요? :)

[쿠어클#15] 가상화 한방 정리

[쿠버네티스 어나더 클래스] Sprint3의 첫 번째 강의 주제는 가상화 한방정리 입니다. 그동안 컨테이너 한방정리와 데브옵스 한방정리가 있었고, 이번이 3번째네요. 😀 먼저, 해당 강의 내용에 대한 소개를 드리면, 가상화가 나온지는 오래되긴 했는데, 컨테이너나 데브옵스 처럼, IT를 하는 사람들이라면 누구나 알아야되는 분야가 아니긴 해요. 게다가 로우레벨의 기술이라 재미도 없고, 또 어렵고요. 이걸 안다고 해도 이 분야에서 전문적으로 일을 하는 사람이 아니고서야 크게 메리트가 없습니다. 그냥 VirtualBox나 다른 가상화 도구들을 잘 쓰기만 해도 충분한데, 그만큼 가상화가 많이 발전하고 추상화 되버린 거죠.그래서 이 세션에서는 가상화 한방정리이지만 가상화 기술만을 중점적으로 다루지는 않습니다. 가상화보다 더 큰 개념들을 보면서 가상화에 대한 포지션을 알려드리고, 이후 본격적으로 가상화에 대한 설명을 드릴텐데, 쿠버네티스와 관련된 가상화에 대한 얘기를 할 거에요. 그리고 이번 블로그에서는 누구나 알고 있는 가상화 기술 비교와 쿠버네티에서 가장 어려운 리소스에 대한 얘기를 해보겠습니다.누구나 알고 있는 가상화 기술 비교VM 가상화 부터 설명드리면, 이렇게 호스트 가상화와 하이버파이저 가상화가 있고. 호스트 가상화가 물리 서버에 Host OS로 운영체제가 있고, 그 위에 여러 종류에 하이퍼바이저가 있어서VM을 만드는 방식입니다. 그리고 사용자가 원하는 Guest OS를 설치하게 되는데, 이 호스트 가상화는 자신이 주로 쓰는 운영체제가 있고, 그 외에 보조 적인 운영체제가 일시적으로 필요할 때 많이 쓰는 방식이고요.하이퍼바이저 가상화는 물리 서버위에 바로 하이퍼바이저가 있어서 Host OS 없이 VM이 만들어 지는 구조 에요. 마찬가지로 사용자가 원하는 Guest OS를 설치하지만, Host OS가 없기 때문에 이 호스트 가상화보다 성능이 더 좋다고 볼 수가 있습니다. 하지만 VM을 생성하고 관리하는데 어려울 수는 있는데, 이 Guest OS가 특정 App이나 사용자에 대한 메인 운영체제로 쓰이는 통상 데이터 센터에서 주로 사용을 해요.데이터 센터에는 보안상 외부와 차단된 네트워크 망이 구성되고, 내부 서버들 끼리만 통신이 되는데, 그렇다고 개발 업무도 이 데이터 센터에서 할 수는 없고요. 외부에서 접근을 하려면 VDI라고 해서 외부 사용자에 대한 인증을 거쳐서, 이 사용자 세션에 대해서만 VM에 접속해서 작업을 할 수 있게 해줍니다. 그리고 단순 원격 접속이기 때문에 이 VM으로 부터 내 PC로 데이터를 가져오지도 못하고요.그래서 이렇게 데이터센터가 있는 기업들은 자사의 데이터를 보호하기 위한 솔루션을 적용하는데, 그런 솔루션이 알아서 하이퍼바이저 가상화로 VM들도 관리를 해주기 때문에 어려울 부분은 없습니다.그래서 VM 가상화에는 대표적으로 이 두 가지가 있지만, 현재 대중적으로 크게 관심을 끌 만한 기술이 아니고요. 요즘은 쿠버네티스가 대두 되면서 VM과 컨테이너 가상화에 대한 비교를 많이 하죠.구성을 보면, 호스트 가상화랑 마찬가지로 Host OS 위에 하이퍼바이저와 같은 역할을 하는 컨테이너 런타임이 있고요.그래서 컨테이너를 만들어 주는 구조까지는 똑같은데, 그 내용을 보면 이 VM에는 GuestOS도 있고, 패키지들(Bins/Libs)도 App 뿐만아니라 OS에 관련된 모든 패키지들이 있는 데 반해, 컨테이너에는 GuestOS도 없고 이 App에 필요한 패키지들이 포함이 되는 구조예요. 그래서 결국 VM은 사이즈도 크고 GuestOS를 위한 추가 리소스가 더 필요합니다. 컨테이너의 경우 이 컨테이너가 HostOS의 커널을 공유하기 때문에 이렇게 App이랑 최소한의 추가 패키지들만 가지고 동작 시킬 수 있는 거고요. 이에 따른 장점은 명확합니다. 사이즈가 작아지기 때문에 다운받기도 빨라지는 등 이동적인 면에서 편리하고요. VM에는 GuestOS 기동시간이 있는데 비해서, 컨테이너는 App만 기동하면 되기 때문에 상대적으로 시작과 종료가 빨라집니다. 그래서 결국 자연스럽게 자원 사용에 대한 효율도 높아지게 되는 거죠.그리고 이런 컨테이너를 만들어주는 컨테이너 런타임에 대해서 말씀드리면, 이전 컨테이너 한방정리때 설명드렸던 내용인데, 컨테이너 런타임에는 High 레벨로는 도커나 컨테어너디 그리고 cir-o가 있고, 모두 Low Level인 runC를 사용하는 구조예요. 그리고 이 runC가 OCI라고해서 표준 규격의 컨테이너를 만들어 주기 때문에, 다른 런타임에서도 이런 표준 규격으로 컨테이너를 만든다면 서로 컨테이너를 공유해서 사용할 수가 있어요. 그 방법으로 리눅스 커널에는 이런 기술들이 있고요. 간략하게 이 기술들에 대해서 설명드리면, chroot는 각 프로세스 별로 루트 디렉토리를 할당해 줘서 서로 파일을 분리시키는 거고요. namespace는 HostOS의 시스템들을 프로세스 별로 각각 분리해서 만들어 주는데, 시스템 종류에는 마운팅이라던지 프로세스 id나 유저 등 여러가지가 있습니다. 이런걸 프로세스 별로 각각 할당해 주는거예요.마지막으로 cgroup은 프로세스 별로 HostOS에 리소스를 분리해서 할당해주는 기술이고요. 이 리소스에는 우리가 흔히 아는 메모리나 cpu, 네트워크 들이 있는거죠.그래서 한 프로세스에는 이렇게 디렉토리나 시스템, 그리고 리소스가 할당이 되서 독립적으로 관리가 되는데 이걸 우리는 컨테이너라고 부르는 겁니다.다음으로 쿠버네티스에서 가장 어려운 리소스에 대해서 말씀을 드려 볼게요. 쿠버네티스에서 가장 어려운 리소스바로 아래 세 가지 리소스 입니다.다른 리소스들도 많지만, 이 세 가지 리소스만 제대로 알면, 다른 리소스들은 결국 이 리소스스들 위한 보조 기능이라고 말할 수 있고요. 만약 처음 쿠버네티스 리소스를 만든다면 이 세가지를 확실히 한 다음에 다음 리소스들에 대한 세팅을 마춰 나가시면 됩니다.그만큼 중요한 리소스고요. 앞으로 Sprint3 전체 강의에서 이 리소스들을 상세하게 배워나갈 꺼지만, 여기서는 이 세 가지가 정말 중요할 수 밖에 없는 이유와 또 복잡할 수 밖에 없는 이유 대해서 말씀을 드릴께요.물리 서버들이 있고, 이 서버들은 게이트웨이에 연결이 되서 사내 네트워크 망이 만들어져요. 그리고 이 게이트웨이에 라우터를 붙이면, 기업 외부 인터넷으로 나가거나 외부 사용자들이 내 서비스에 들어 올 수 있게 되요. 그리고 그 서비스에 대한 데이터를 안전하게 보관하기 위해서 이 서버에 스토리지도 붙여 놔야 됩니다.그래서 이렇게 이전부터 이 서버와 네트워크 그리고 스토리지는 App을 서비스 하기 위한 기본 구성이었던 거죠. 이 부분을 편하게 갈려면 클라우드 서비스를 쓰는 거고요.이 물리적인 구성들이 쿠버네티스에서는 Pod와 Service 그리고 PV로 대신 사용하는 거기 때문에 이 세가지 리소스가 가장 중요하다고 말씀을 드리는 거예요.그리고 이제 이 세가지가 또 복잡할 수 밖에 없는 이유에 대해서 말씀을 드리면,물리 서버의 경우, 서버실에 서버가 많아 질 수록 서버실 공간도 커져야 되고, 그럼 전기세도 많이 들어요. 그래서 고 사양의 서버 한 대를 설치하고 위와 같이 가상화를 시켜서 쓰는 게 비용적으로 더 효율적입니다. 그렇기 때문에 쿠버네티스도 결국 이 가상화된 VM위에 올라가지게 되요. 그리고 이제 내부로 들어가서 Pod를 보면, 먼저 CRI라고 해서 컨테이너 런타임 인터페이스로 이런 제품들을 설치할 수가 있고요. 그럼 이 런타임들이 컨테이너를 만들어 주고, 이 컨테이너가 바로 하나의 App이 되는 셈인데, 쿠버네티스는 Pod라는 개념안에 이 컨테이너가 들어 있기 때문에 결국 App을 대표하는게 Pod가 되는거죠.그래서 이전에 VM위에 App을 띄었던 게 Pod라는 엄청 추상화된 리소스에 들어가게 되고요.App으로 사용자의 트래픽이 들어와야 되고요. App에서 만들어지는 데이터도 어딘가에 저장을 해야되야 되는데, 쿠버네티스에서는 그걸 하기 위한 리소스로 Service와 PV가 있는 겁니다.다음으로 Service를 보면, 쿠버네티스에서는 CNI라고해서 컨테이너 네트워크 인터페이스로 여러가지 제품들이 있어요. 저희는 여기서 칼리코를 설치했던 거고요. 이게 오버레이 네트워크라고해서 컨테이너들 간에 통신을 할 수 있게 해줘요.그리고 이 네트워크가 내 운영체제 위에 있는 IPTables랑 연결이 되서 실제 물리적인 서버로 가야 되는데, 그 사이 구간에 또 가상화된 네트워크가 있습니다. 저희는 쿠버네티스를 설치할 때 가상화 도구로 Virtualbox를 썼고요. 여기서 제공해주는 네트워크를 사용했었어요.그래서 이렇게 이 가상화 구간에 대한 네트워크 방식이 있고. 또 이 실제 물리 구성단에 네트워크 방식도 다양하기 때문에 네트워크는 알면 알 수록 어려운 분야지만 그래도 이 그림 정도는 알아야 Service에서 제공하는 타입들에 대해서 이해를 할 수 있게 됩니다.ClusterIP는 컨테이너 간의 네트워크고요. NodePort는 이 VM의 네트워크를 말해요. 그리고 LoadBlancer는 클라우드 서비스 상에서의 네트워크고요. 그리고 이 ExternalName는 DNS 서버와 관련이 있거든요.쿠버네티스를 설치하면 CoreDNS라는 서버도 같이 구성이 되는데, 이 CoreDNS가 서비스가 새로 만들어지면 이름이랑 IP 주소를 자동으로 등록해 놓기 때문에 우리는 특정 Pod에서 Service에 이름으로만 호출을 해도 CoreDNS로 부터 실제 IP를 받아서 원하는 Service로 트래픽을 전달 할 수 있게 됩니다.그리고 회사 내에도 쿠버네티스가 아닌 기존에 VM들을 도메인으로 호출하기 위한 사내 DNS서버가 있을 수 있거든요. 만약 컨테이너 안에서 도메인 명으로 VM에 있는 서비스를 호출하고 싶으면, 이렇게 CoreDNS서버에 이 사내 DNS서버를 업스트림 서버로 설정해 놓으면 됩니다. 결론적으로 Service는 이 네트워크 구성들을 알아야, 더 잘 쓸 수가 있다는 거죠.글고 이제 마지막으로 PV를 보면,PV를 잘 다루려면 이 스토리지에는 여러 종류의 스토리지들이 있다는 걸 알아야 되요. 쿠버네티스에서는 PV로 제공되는 옵션을 보면 ReadWriteMany는 파일 스토리지를 가리키고, ReadWriteOnce는 블록 스토리지를 주로 의미하거든요.그리고 쿠버네티스에서는 CSI라고 해서 Pod 에서 실제 스토리지로 까지 연결 해주기 위한 여러 솔루션들이 있고요. 그래서 이걸 내용들을 잘 알아야. 내가 저장하려는 데이터가 어떤 종류인지에 따라 그에 맞는 스토리지를 결정하고, 또 그걸 지원해주는 솔루션을 절 선택할 수가 있는 거죠. 그래서 여기까지 쿠버네티스에서 가장 어려운 리소스에 대해서 말씀을 드렸는데, 이제 좀 이 세가지 리소스가 Sprint1에서 배웠던 리소스 들중에서 무게감이 좀 다를 거 같다는 느낌이 드시나요?그럼 이번 블로그는 여기까지고요, 해당 강의에서는 아래 내용들에 대해서 더 다룹니다 😀[쿠버네티스 어나더 클래스] : https://inf.run/unreTIT에는 어떤 직군들이 있을까? 한번쯤 알고 넘어가면 좋을 서비스 모델 아무나 모르는 컨테이너 기술의 장점쿠버네티스에 대한 단점ps. 블로그 내용이 도움이 되셨다면 좋아요♡ 부탁 드립니다 :)

[쿠어클#14] ArgoCD 빠르게 레벨업 하기

Sprint2 추가 강의가 업로드 됐어요! 이번 수업에서는 ArgoCD의 아키텍처에 대해서 설명을 드리겠습니다.먼저 Argo 제품들에 대한 설명부터 드릴게요.ArgoCD는 쿠버네티스 전용 배포 툴이고, 릴리즈 파일 저장소로 Git을 반드시 필요로 해요. 그래서 ArgoCD를 쓰려면 쿠버네티스는 당연한 거고, 변경관리 저장소가 꼭 Git이어야 합니다.이전에 제가 했던 프로젝트에서는 형상관리를 SVN으로 썼거든요. SI 프로젝트에서는 개발량이 많기 때문에, 그 많은 기능들이 오픈 때까지 일단 다 돌아가는 게 하는 게 중요하지. 상대방의 코드를 리뷰 할 시간이 별로 없어요. 그래서 Git을 사용하는 문화를 정착 시키기 보다 최소한의 기능으로 누구나 빨리 익히고 쓸 수 있는 SVN을 더 선호하게 됩니다. 근데 그러면 ArgoCD는 사용할 수가 없는 거죠.다음으로 ImageUpdater는 ArgoCD의 추가 기능이에요. 이걸 사용하면 도커 허브에서 컨테이너 이미지에 대한 변경을 감지해서 배포를 할 수 있는 파이프라인을 만들 수 있습니다.그리고 BlueGreen과 Canary와 같은 고급 배포를 지원해주는 Rollouts가 있고요.다음으로 Events는 카프카와 같은 역할을 하는 솔루션이라고 보시면 되요. 통상 카프카를 이용해서 이벤트 버스 구조의 아키텍쳐를 만드는데, 이벤트 버스에 대해서는 여기서 설명을 드리기엔 큰 주제라 한번 검색을 해보시길 바라고요. 아시는 분들은 argo에서도 그런 역할을 해주는 제품이 있다고 보면 됩니다. 그리고 Workflow는 airflow나 kubeflow와 같은 역할을 하는 워크플로우 매니지먼트 도구고요. 역시 잘 모르시는 분은 추가적인 검색을 해보시면 좋은데, 결국 Argo 제품만을 가지고 아래와 같은 아키텍처가 만들어 질 수 있어요.Argo Events는 시스템들간에 이벤트를 주고 받는 메인 통로 역할을 해주고요. 이 중에 Workflow로 보내지는 이벤트가 있을 수 있고, workflow 안에는 받은 이벤트에 내부 값에 따라서 어떤 작업을 실행하라는 순서도가 있는거죠. 그래서 그 워크 플로우에 결과에 따라서 작업이 실행 되는데, 그 중에 배포를 하라는 작업이 있을 수 있고, 그럼 CD가 실행이 되요. 그리고 Rollous를 통해서 특정 배포 전략으로 쿠버네티스에 자원을 생성 시켜 주는거죠.그럼 이 제품들의 쓰임에 대해서 대략적인 맥락이 보이나요? 이제 ArgoCD가 쿠버네티스에 설치됐을 때 아키텍쳐에 대해서 설명을 드릴게요.먼저 쿠버네티스 컴포넌트들은 아래와 같이 구성돼 있고요.우리는 30000번 포트를 통해서 UI에 접근하거나, Kubectl로 CLI를 날렸었죠? 그럼 kube-apiserver가 API를 받아서 관련된 컴포넌트들 한테 트래픽을 전달을 해주는 구조였는데, 이런 구조는 다른 솔루션들도 비슷합니다. 먼저 이 Server는 API Server 와 Dashboard 역할을 동시에 합니다. 그래서 nodeport로 ArgoCD UI에 접속을 할 수 있고 kubectl처럼 argocd 라는 툴을 설치해서 CLI를 날릴 수도 있어요. 다음으로 Github가 있고, 여기에 내 App에 대해서 배포할 yaml 파일이 있다고 해볼게요. 그럼 Repo Server는 Git에 연결해서 yaml 파일을 가져오고 그걸로 ArgoCD에 배포할 yaml 매니패스트를 만들어 놓는 역할을 해요.그리고 Applicaiton Controller는 쿠버네티스에 리소스를 모니터링 하면서 이 Git에서 받은 내용과 다른 게 있는지 비교를 해주고요. 그래서 내용이 다르면, Git에 있는 내용으로 배포가 진행됩니다. 그리고 Kube API가 쿠버네티스로 리소스 생성 명령을 날려주는 역할을 하고요. 그리고 Notification은 ArgoCD에서 발생하는 이벤트를 외부로 트리거 해주는 역할을 담당해요. 그리고 Dex는 외부 인증관리를 하는 역할인데, 쿠버네티스를 하다보면 Grafana 나 이외에도 다양한 Dashobard들을 많이 쓰게 되거든요. 근데 관리자 입장에서 그 UI마다 ID/Password를 만들고 관리하기가 참 번거롭죠. 그래서 흔히 IAM 솔루션을 사용하는데, 그럼 사용자가 여기에다가만 로그인을 하면 이 IAM솔루션이랑 연결된 시스템에는 별도로 로그인을 안해도 자동 로그인이 되는 거죠. 흔히 SSO라고 하고요. 쿠버네티스에서는 대표적으로 KeyCloak이 있어요.Redis는 아시는 분은 잘 아시겠지만, 메모리 DB에요. 통상 시스템에서 캐시역할을 많이 하는 데, ArgoCD에서는 여기 Github와 연동되는 구간이랑 kube-apiserver랑 연동되는 구간에 캐시로 쓰여서. 불필요한 통신을 줄여주는 기능을 합니다. 그리고 마지막으로는 ApplicationSet Controller는 멀티 클러스터를 위한 App 패키징 관리 역할인데, 이게 뭐냐면 ArgoCD는 이렇게 클러스터마다 설치를 할 수도 있지만 이렇게 하나만 설치해서 여러 클러스터로 App을 배포할 수도 있다고 했잖아요? 그럼 배포 환경마다 ArgoCD에서 배포 구성을 만들어 줘야 하는데, 그럼 또 중복되는 구성들이 생기기 때문에, ApplicationSet Controller가 환경별로 다른 부분만 세팅해서 사용할 수 있는 템플릿을 제공해 줘요. 마치 Helm이랑 Kustomize에서 했던 것 처럼요.그래서 여기까지가 ArgoCD 아키텍쳐에 대한 설명을 드린거고, 처음 한번 정도는 이런 전체적인 구성들을 이해하면 좋은 게내가 ArgoCD에 기능에 일부만 쓰고 있더라도, 내가 알지만 안 쓰는 거지 기능을 몰라서 안 쓰는 건 아니라는 안심이 생겨요!이제 Argo App들을 어떻게 설치하는 보면,이 강의에서는 3개를 설치해 볼 거고. 이 제품들은 모두 Artifact Hub에서 Helm 패키지로 설치를 할 수가 있거든요. 그래서 이 패키지들에 특정 버전을 다운 받아서 제 강의 레파지토리에 그대로 복사를 해 놨고, 이 강의 실습 환경에 맞는 values 파일을 추가 했어요.그리고 이제 강의를 실습 하시는 분들께서는 본인에 클러스터에 설치를 하려면, CI/CD Server에 Jenkins로 Argo App들을 설치하는 잡을 하나 만들고요. 실행을 하면, 제 Github에서 패키지를 다운받은 다음에 본인에 쿠버네티스 클러스터로 설치가 됩니다. 이제 ArgoCD에서 Application을 만들어 보겠습니다. 우리는 배포를 하기 위해서 Application 이라는 걸 만들어야 되요. 이건 젠킨스에서 배포 단위 별로 프로젝트를 만들었던 거랑 똑같은 개념이고요. 하나의 app을 배포하는 단위가 Application인거고. 그럼 Application은 App별로 여러 개 만들어 지겠죠?그리고 Default라는 Project에 소속 되는데, 이 Project는 Application을 그룹핑 하는 용도고, 쿠버네티스에 네임스페이스 같이 Default라는 프로젝트가 기본적으로 만들어져 있어요.이제 이 Application을 만들 때 어떤 내용들을 넣어야 되는지 볼게요.먼저 Source라고해서 연동할 Git에 대한 정보를 입력해야 되요. 그리고 Destination이라고 해서 배포할 쿠버네티스 클러스터 정보도 줘야 됩니다. 너무 당연한 항목이죠?근데 생소할 수 있는 용어가 있는데, Refresh랑 Synchronize고요. ArgoCD UI에도 이 버튼들이 있는데,, Git에 연결을 해 놓으면 자동으로 변경 사항을 감지하지만, 3분 정도에 체크 인터벌이 있는데, 이때 Refresh 버튼을 누르면 바로 변경 사항을 체크 해줍니다. 그리고 Sync버튼을 누르면 쿠버네티스에 배포하는 실행하는 거고요.이제 또 다른 항목으로 General이 있고, 기본 정보나 배포시에 줄 옵션들이 들어가요. 여기서 주목할 옵션으로 Sync Policy가 있고요. 리소스에 대한 변경사항이 감지 됐다면, 이제 수동으로 배포할 지, 자동으로 배포할 지를 선택하는 옵션이고, 자동으로 할 경우에는 3분 이내에 배포가 됩니다.그리고 Sync Option은 배포 상세 옵션으로, 여러가지가 있는데, 예를 들어 배포할 때 네임스페이스를 자동생성 할 건지? 같은 배포시에 줄 수 있을 법한 기능들이 있고요.Prune Policy는 리소스 삭제 정책에 대한 부분이고. 그외에도 몇 가지 더 있긴 한데 대략 이정도 느낌에 설정들이 있다는 것만 알고 넘어갈게요. 마지막으로 이렇게 ArgoCD에서는 3가지 배포 방식에 배포 툴을 지원합니다. 그래서 내 릴리즈 파일이 어떤 방식 인지에 따라서 선택을 해주면 되는데, ArgoCD가 릴리즈 파일을 다운 받으면서 자동으로 인식을 해요.그럼 이번 블로그는 여기까지고요, 해당 강의에서는 실습과 더불어 추가적으로 아래 내용들에 대해서 더 다룹니다 😀[쿠버네티스 어나더 클래스] : https://inf.run/unreT ArgoCD Image Updater를 이용한 이미지 자동 배포 Argo Rollouts를 이용한 배포 - BlueGreenArgo Rollouts를 이용한 배포 - Canaryps. 매너가 좋아요♡를 만든다 :)

[쿠어클#13] Helm과 Kustomize 비교하며 사용하기 (2/2)

Sprint2 추가 강의가 업로드 됐어요! Helm과 Kustomize 비교하며 사용하기 두 번째 시간입니다. 이번 시간에는 Kustomize 패키지 구조를 설명을 드릴 거예요.먼저 최초 패키지를 만드는 방법을 보면, Helm 패키지는 이렇게 helm create 명령을 날리면 이런 구조의 패키지가 자동으로 만들어졌는데, Kustomize는 직접 폴더를 만들어야 되고요. 그리고 이 폴더 밑에 이렇게 하위 폴더 구성도 직접 만들어야 되요.어려운 구조는 아니지만 그래도 사전에 Kustomize의 구성이 이렇다라는 건 미리 알고 있어야 되는 거죠. (물론 Kustomize 가이드에 잘 나와 있어요) 그리고 아래와 같이 각 폴더 밑에 내가 배포할 yaml 파일들도 만들어 줍니다.좀 수동으로 만들어야 할 부분이 많긴 한데, Helm은 알고 있어야 되는 파일들이 많았던 거 에 비해서 Kustomize는 파일 구조가 간단해 보이죠? 이 폴더 구조랑 이 kustomization 파일에 기능만 알면 다 예요.그래서 하나씩 보면, 메인 폴더가 있고 밑에 base는 Default 포맷이 될 yaml 파일들을 넣는 폴더입니다. 기존부터 kubectl로 배포하던 deployment yaml 파일을 그대로 여기에 넣으면, 이게 베이스 yaml 파일이 되는 거예요. 이런 식으로 밑에 배포할 파일들을 다 넣으면 되요.그리고 Kustomization.yaml이 제일 중요한 파일 입니다. 리소스 yaml 파일들 중에서 어떤 파일을 배포할 건지 선택하는 내용이 있고, 또 그 yaml 파일들에서 반복적으로 사용하는 속성들을 공통값을 설정할 수 있어요. 먼저 어떤 파일을 배포할 건지 선택하는 방법은helm의 경우, hpa.yaml 파일 내부에 이렇게 if문이 있고, values.yaml 파일에서 이렇게 false를 하면 이 hpa가 배포가 안됐고요. kustomize는 이 Kustomization 파일에 [resouce] 키가 있어서 내가 배포할 파일들만 명시적으로 정할 수 있어요.이게 배포할 파일을 선택하는데 있어서 두 패키지 매니저에 대한 차이 입니다.그리고 공통값 설정에 대한 차이는Helm은 Deployment 템플릿 내에 변수를 넣는 부분이 있고, 여러 파일들(_helpers.tpl, Chart.yaml, values.yaml)에서 변수를 주입하는 방식이 다양했었죠?반면 kustomize는 Deployment에는 특별한 내용이 없고, Kustomization.yaml 파일에 명시적으로 coommonLabels라는 키가 있어서 여기에 내용을 넣으면, 배포될 모든 yaml 파일에 label로 그 내용이 들어가 집니다.마지막으로 환경별로 배포할 때 기본값 들을 어떻게 주는지 말씀 드릴게요.kustomize는 overlays 폴더 밑에 환경별로 폴더를 만들고, 해당 폴더마다 그 환경에 맞는 yaml 파일들을 넣어 놓습니다.그리고 여기에도 마찬가지로 Kustomization.yaml 파일이 있는데, 하는 역할은 같아요.각 환경별 파일에 있는 yaml 파일들에 대해서 배포할 파일을 지정하고 공통값을 설정할 수가 있습니다. 그래서 개발 환경을 배포 하려면 [kubectl apply -k ./app/overlays/dev] 처럼, 배포 명령에 해당 환경별 폴더 경로를 주면 되고요. 반면 Helm의 경우, values.yaml 파일을 각각의 환경별로 추가하고, 배포할 때 -f 옵션으로 이 원하는 환경의 values-dev.yaml 파일을 선택하면 됩니다. 헬름은 변수를 가져다 쓰는 방법이 다양했는데, 또 한 가지가 더 늘었죠? 그래도 다 사용해야 되는 상황이 있고, 실습을 하면서 자세하게 설명을 드릴게요. 그럼 이번 블로그는 여기까지고요, 해당 강의에서는 실습과 더불어 추가적으로 아래 내용들에 대해서 더 다룹니다 😀[쿠버네티스 어나더 클래스] : https://inf.run/unreT 배포 파이프라인 구축 후 마주하게 되는 고민들ps. 매너가 좋아요♡를 만든다 :)

[쿠어클#12] Helm과 Kustomize 비교하며 사용하기 (1/2)

Sprint2 추가 강의가 업로드 됐어요! 이번 강의는 Helm과 Kustomize 비교하며 사용하기라는 주제 입니다. 지금까지 kubectl을 잘 쓰고 있었는데, Helm이랑 Kustomize를 꼭 써야 되나요? 라고 질문을 하시는 분들께 저는 무조건 그래야 한다고 말씀을 드려요. 왜 그런지는 아래 그림을 보면서 말씀 드릴께요! 먼저 이렇게 배포툴(Jenkins, argo)이 있어요. 지금까지 젠킨스를 배포툴로 써왔는 데, 다음시간에는 argoCD를 배포툴로 쓸꺼고요. 그리고 이 배포툴에서 kubectl을 써서 쿠버네티스로 배포를 해왔었죠.이 kubectl은 단지 커맨드라인 도구인 CLI인 거고, 이 명령중에서 create나 apply 명령으로 쿠버네티스에 자원을 생성했었는데, 그건 그냥 CLI 명령중에 하나를 사용한거지, 배포를 위한 부가 기능은 없어요. 그리고 실무에서는 이 kubectl을 배포한 쿠버네티스 자원을 조회하거나 급한 수정을 해야 될 때 주로 쓰지, 정작 자원을 생성할 때는 잘 쓰지 않습니다. 실제 자원 생성은 주로 Helm이랑 Kustomize를 통해서 해요. kubectl이랑 같은 위치로 들어가고요. 얘네들을 패키지 매니저라고 부릅니다. 똑같은 구조처럼 보이지만 차이가 있는데요. 결국 kube-apiserver한테는 똑같이 6번에 API를 날려주지만, 작업자의 입장에서는 이 yaml 파일들을 명령어 한번으로 배포할 수 있게 해줘요. 어차피 App 하나를 구성하는데 여러 yaml 파일들이 사용되기 때문에, 이 yaml 파일들을 패키지 형태로 관리 할 수 있게 필요하기도 했거든요. 그런 니즈에 잘 마춰 졌고, 그렇기 때문에 이번 수업을 통해서 패키지 매니저인 Helm과 Kustomize에 대해서 잘 알고 있어야 합니다. Helm vs Kustomize 비교 - 최종 정리공통점을 말씀드리면, 바로 사용 목적입니다. 배포를 하기 위해 만들어야 되는 yaml 파일들에 대해서 중복관리하는 걸 최소화 하기 위한 거죠. 이전 시간에 한번 말씀드릴 적 있죠? 이젠 마이크로 서비스 아키텍처를 많이 쓰다 보니까, App을 잘게 쪼개게 되고, 그래서 App 종류가 많아졌어요. 그리고 기존부터 그랬던 부분인 다양한 환경에 배포를 해야되서 그렇고요.그리고 두 번째 공통점으로 이 두 패키지 매니저는 다양한 배포툴에서 지원을 합니다. 지원한다는 의미는 이 툴 에서 helm이나 Kustomize를 더 편하게 쓸 수 있도록 부가적인 기능들을 제공한다는 거죠.이제 다음으로 차이점인데, 지금부터 내용은 그냥 그렇구나 정도로만 알고 넘어가 주세요. 해보지 않은건 크게 와닿지가 않거든요. 이걸 외울 필요도 없고요. 그냥 이번 강의를 쭉 듣다보면 자연스럽게 알게되는 내용들이기도 해요. 먼저 배포 편의기능이 Helm은 200개 정도 되는 거에 비해 kustomize는 10개 정도 밖에 안됩니다. 딱 그렇다는게 아니라 상대적인 비교예요. 근데 “그래서 Helm이 더 좋아요”라고 말할려는 게 아니라, Kustomize는 심플 쓸 수 있다는 장점이 있는 거거든요. “지금 파이프라인을 구축하는데 많은 기능이 필요 없고 빨리 공부해서 구축을 해야 되” 라고 했을 때는 kustomize를 써야 되는 건 거죠. 그리고 다음으로 각각에 패키지 매니저를 이용해서 하나에 패키지를 만들어 었을 때, 그 패키지를 활용 할 수 있는 범위인데 (이건 제가 권고 사항이고요) Helm은 한 패키지를 만들어서 마이크로 서비스 목적이랑 이 다양한 환경으로 배포까지 하는데까지 사용 해도 좋아요. 패키지를 구성할 때 이 두 목적을 모두 챙기면서 만들 수 있다는 거고요.Kustomize는 OR이에요. 둘 중 한 목적만 선택해서 패키지를 구성하는게 좋습니다. 불가능 한건 아닌데, 활용 범위를 늘릴 수록 점점 패키지 내부에 파일량이 많아지는 구조라서 그래요. 그럼 또 이 파일들을 관리하는 게 복잡해지기 시작합니다. 다음으로 사용 목적입니다. Kustomize는 딱 내 프로젝트에 App을 패키지화 시켜서 배포하는 목적으로 쓰이고, Helm은 그거 받고, 기업용 제품을 패키지 하는데 쓰여요. 대부분에 오픈소스들은 여러가지 설치 방법들을 제공하잖아요? 그중에 하나로 꼭 들어가는 설치 방법이 Helm인 거죠. 보통 오픈소스를 설치하는 사람들이 각자 환경이 다르고, 설치하고 싶은 구성이 조금씩 다를 수가 있잖아요? Helm은 그런 상황에 따라서 각자, 자신의 환경에 따라 조절할 수 있도록 패키지를 만들 수 있습니다. 그래서 유즈케이스를 보면, Helm은 App이 5개 이상있고, 주로 대형 프로젝트를 할 때 많이 쓰고요. Kustomize는 App 종류가 5개 미만에 간단한 프로젝트를 할 때 쓴다고 볼 수가 있어요. Helm vs Kustomize 비교 - 설치 구성 kustomize를 보면, 자체적으로 kustomize를 관리하는 사이트가 있고, 다운을 받거나 Release를 관리 하는 Github도 있어요. 근데 이게 1.14버전부터는 Kubectl에 통합이 됐거든요. 그래서 현재 우리가 쿠버네티스 레파지토리에서 kubectl을 받아서 설치했는데, 현재 kubectl는 1.27버전 이기 때문에 kustomize가 포함이 돼있고 바로 사용할 수 있다고 보시면 됩니다.Helm도 마찬가지로 Helm 사이트가 있고, Github에서 Helm을 다운 받아서 설치 합니다. 그리고 kubectl이랑 마찬가지로 이렇게 인증서가 있어야지 kube-apiserver로 통신을 할 수 가 있는 거고요. 그래서 이렇게 설치되는 방식은 좀 다르지만, 구성은 결국 비슷하죠? 이렇게 패키지를 만들면 Helm은 helm으로 시작하는 명령어를 날려서 API가 보내지는 거고, Kustomize는 kubectl에 포함이 됐기 때문에 kubectl 명령에 -k가 kustomize를 쓴다는 옵션이예요.그래서 여기까지보면 둘 다 구성이 비슷해 보일 수는 있는데.. 여기서 Helm은 좀더 큰 생태계를 가지고 있어요. Artifact Hub라고 해서 Helm 패키지들을 저장하는 저장소가 있습니다.Github나 DockerHub 같은 곳이라고 보면 되는데, 이렇게 많은 오픈소스 기업들에서 자신들에 제품들을 Helm 패키지로 설치할 수 있도록 패키지들을 올려놓습니다.그래서 이중에서 설치하고 싶은 게 있으면, Helm 명령어로 필요한 패키지를 다운 받을 수 있는 거죠. 그래서 이렇게 패키지가 받아지고, 내 환경에 맞게 좀 수정해야 되는데, 그건 이걸 올려놓은 기업에서 설치 가이드도 자세히 제공하고 있고요. 그래서 이렇게 더 큰 생태계가 있으니까 그만큼 Helm에서 제공해줘야 하는 기능이 많을 수 밖에 없어 보이죠?그럼 이번 블로그는 여기까지고요, 해당 강의에서는 실습과 더불어 추가적으로 아래 내용들에 대해서 더 다룹니다 😀[쿠버네티스 어나더 클래스] : https://inf.run/unreT Helm vs Kustomize 비교 - 사용방식 [Helm 차트] 구조 상세 설명 [Helm 차트] 변수 사용ps. 매너가 좋아요♡를 만든다 :)

[쿠어클#11] Jenkins Pipeline 기초부터 Blue-Green까지

Sprint2 추가 강의가 업로드 됐어요!이번 강의에서는 Jenkins Pipeline 기초부터 Blue/Green까지라는 주제 입니다. Step 1. Jenkins Pipeline 기본 구성 만들기Step1으로 Jenkins Pipeline에 대한 기본 구성을 만들어 볼거고, Github에서 릴리즈 파일들을 가져와서 빌드/배포하는 구성을 이번에는 젠킨스 파이프라인으로 만들어 보겠습니다. Step 2. Github 연결 및 파이프라인 세분화두 번째 Step은 Github 연결과 파이프라인 세분화인데, Jenknis Pipeline을 쓰는 이유인 파이프라인 스크립트를 Github에서 가져오고, 파이프라인을 좀더 세분화 시켜볼꺼예요. 이렇게 세분화 하면 좋은 점이 각 구간별로 시간이 얼마나 걸리는지 바로 보이기 때문에 이전 배포보다 왜 느려졌는지 눈에 잘 뛰기도 하고, 생각보다 오래 걸리는 구간이 있으면 개선 포인트로 잡기도 좋아요. Step 3, 4. Blue/Green 배포 만들기 및 특징 실습다음으로 Blue/Green 배포를 만듭니다. 처음 Blue가 배포된 상태에서, Green 배포를 하고, V2 버전에 Deployment가 생성이 되면, 트래픽을 V2로 전환 합니다. Service의 Selector를 변경할 거고요. 그런 다음 v1 Deployment를 삭제하면, 이 Blue 배포가 없어지는 거죠. 근데 이 과정 중에서 유즈케이스로 말씀드렸던 운영에서만 테스트 가능한 경우를 하나 해볼 거고, 다음으로 수동 배포시 롤백이 빠르다는 것도 해볼 거예요. 그래서 여기까지가 수동으로 Blue/Green 배포를 할 때 해볼 수 있는 실습들입니다. 다음으로 Step4로는 버튼 한번으로 자동 배포가 되는 Script를 만들고, V2에 과도한 트래픽을 유입 시켰을 때 V2 Pod에 문제가 발생할 수 있는 부분은 실습 환경을 구성하기가 쉽지 않게 때문에 별도로 실습을 해보진 않지만 꼭 주의하시길 바랍니다. 실습 내용은 강의에서 다루고 있어요. (https://inf.run/NzKy) Blue/Green 시 고려해야 하는 요소다음으로, Blue/Green시 필요한 요소라고 해서 yaml을 만들 때 어떤 걸 고려해야 되는지를 설명 드리겠습니다. 먼저 왼쪽은 Blue 배포에 대한 yaml 파일이고, 이건 이전 부터 계속 봤왔 던 내용이에요. 그리고 오른쪽은 Green 배포를 위한 Deployment yaml 파일 내용 입니다. 뭐가 다른지 보이시나요? deployment 이름 뒤에 추가적으로 시퀀스가 붙어 있죠? 바로 Blue/Green 배포를 고려한 Deployment에 네이밍이 필요한건데, Blue/Green은 기존배포와 나중배포에 대한 상징적인 표현이고, 배포 할 때마다 계속 새 Deployment를 만들 줘어야 되기 때문에 이렇게 네이밍에 신경을 써줘야 합니다. 다음으로 블루/그린 배포를 위한 추가 레이블 및 셀렉터가 필요해요. 현재 이 레이블 상태라면 Green을 만들자마자 Service가 Green Pod에도 연결을 하겠죠. 그래서 블루/그린 배포를 위한 Selector와 Label을 추가적으로 만들어야 되요. 그리고 Green에는 이렇게 값을 다르게 만들어야 되는 거고요. 그래서 여기까지가 Blue/Green 배포를 한다고 했을 때, 미리 고민해서 구성 해놔야 되는 yaml 파일에 내용 입니다. 이번 강의는 실습이 많은 강의라 블로그에는 이정도까지만 정리하겠습니다 ^^그럼 강의에서 만나요!ps. 뒤로가기 함부로 누르지마라. 너는 누구에게 한 번이라도 좋아요♡를 준 사람이었느냐 :)