깜태

도커를 처음 알게 된 건 2019년쯔음에 AI 쪽에 입문하면서 환경설정으로 애먹던 와중에 도커를 처음 듣고 적용해보았었다. 그러면서 도커에서 GPU를 쓰기 위해 nvidia-docker 부터 시작해서 쿠버네티스까지 이것저것 공부했었기에 나름 많이 안다고 생각했다. 하지만 최근에 다시 보니 표면적인 활용방법만 알았을 뿐, 도커가 어떻게 작동하는지에 대해 깊이 알지 못하단 걸 깨달았고 공부해서 이해해본 내용에 대해서 적어보려고 한다. 가상화(Virtualization) 도커는 리눅스 컨테이너 기반으로 하는 가상화 플랫폼이다. 도커 얘기가 왜 나왔냐부터 시작하면 하이퍼바이저부터 시작하는 가상화에 대한 얘기가 빠질 수 없는 것 같다. 초기의 가상화 모델에 대한 수요는 IBM의 운영체제 아이디어 테스트로부터 시작..

최근에 AWS를 이용해서 이메일 서비스를 할 일이 생겼다. 해당 업무는 주로 회원가입 시 인증번호 메일이나, 비밀번호 찾기, 축하메일 발송, 뉴스레터 등이다. 간단하게 하면 html 한두줄이면 끝나겠지만, 제대로 한다면 CSS까지 적용할 수도 있다. 전제조건으로 AWS에 SES 서비스가 이미 등록되어있고, HTML 파일이 있다는 가정 하에서 시작한다. (등록하는 과정이 엄청 어렵지도 않으니, 다른 글을 참조하면 좋을 것 같다) 1. HTML 템플릿 내 변수 확인하기 나의 경우에는 이메일로 회원가입 시 인증번호를 받는 작업이였다. 절차 상 랜덤으로 인증번호를 생성해서 보내기 때문에, 인증번호라는 변수가 필요했다. 따라서 vericiation_code 라는 변수를 만들었고, 중괄호 2개로 템플릿화시켜 나중에..

상황 secret volume mount로 .secret 이라는 파일을 업로드하고 싶었으나, 디렉토리로 인식되어 파일이 존재하지 않는것으로 인식되었다. 해결방법 subPath를 명시하면 파일로 처리된다. deployment.yaml - name: private-key mountPath: /.secret - name: private-key mountPath: /.secret subPath: .secret 결과 참고 https://stackoverflow.com/questions/65399714/what-is-the-difference-between-subpath-and-mountpath-in-kubernetes https://stackoverflow.com/questions/56395758/what-is-..

상황 설명 쿠버네티스는 논리적으로 노드를 지정할 수 있는 옵션이 있다. 이는 AWS EKS에서는 인스턴스와 직결되고, 인스턴스 타입에 따라 결제금액의 변동이 생긴다. 따라서 파드에 필요한 자원 정도에 따라 알맞은 노드를 지정하는 옵션이 필요할 수 있다. 노드 “하나”를 지정하는 것은 EKS에서는 인스턴스 1개에만 생성하는 것이므로 노드 스케일링을 적용한 나에게는 적절한 옵션이 아닐 수 있기에, 노드”그룹”을 지정하는 옵션이 필요했다. 나의 목적은 개발용으로 쓰는 경우 적은 자원의 노드로 테스트하고, 배포환경에서는 실제로도 큰 자원의 노드로 테스트하고 싶었다. 따라서 devNode는 상대적으로 작은 크기인 t3.medium 크기로 진행하였고, stagingNode는 t3.large로 진행하였다. (apiN..

상황 설명 Private VPC 망에서 간단한 API를 작업할 일이 생겼다. 서버를 구축하기엔 API 빈도가 적어서 오버헤드가 크다고 판단하여, API Gateway + Lambda를 사용하기로 결정했다. API Gateway 에서는 사용하려는 망의 종류에 따라 [”Private”, “Edge”, “Regional”] 으로 분류된다. “Edge” 는 API Gateway를 Cloudfront 와 연결하여 사용하는 방법이고, ”Regional”은 Cloudfront 없이 API Gateway로만 사용하는 방법, ”Private”는 VPC 안에서 사용되는 경우를 말한다. 방법 먼저 zappa를 이용하기로 했다. zappa는 Lambda 쪽에서 Flask의 코드를 배포를 자동화시켜줄 수 있는 도구여서 써보니 ..

상황 어플리케이션이 여러 개 있는 상황에서 URL 별로 로드밸런싱이 필요해졌다. 기존에는 메인 API 서버 하나만 Ingress로 설정하였고, VPC 내부에서 K8S ClusterIP 타입의 서비스를 이용해 다른 서비스를 호출하는 방식으로 해결해왔다. 하지만 서버를 호출하는 객체가 여럿으로 늘고 외부에서 호출할 필요가 생기면서, 어플리케이션 별로 URL 작업이 필요해졌다. 시행착오 배포할 때, argoCD의 applicationSet 배포 패턴을 사용하고 있었다. 처음에는 api 서버 프로젝트의 ingress에다 다른 앱의 서비스를 붙이려고 시도해봤는데, 인식을 못해 타겟그룹도 안생기고 503 에러가 발생했다. backend service does not exist kubernetes 그럼 applica..

1. Jenkins 플러그인 접속 후, Maven Integration Plugin 설치 (이미 설치해서, 설치된 플러그인을 찍음) 2. Jenkins 관리 → Global Tool Integration → Maven 이동 Name 등록 Version 선택 Save 3. Jenkinsfile 수정 withMaven 부분 수정 ( 위에서 설치한 maven 버전 이름 ) withMaven() { sh "mvn clean package" } withMaven(maven: 'maven3.8.1') { sh "mvn clean package" } 참고 https://itkevin.tistory.com/8 https://stackoverflow.com/questions/71085202/error-could-not-..

나의 경우는 EKS 에서 웹에서 생성한 Cluster가 CLI 환경에서 적용되지 않아 발생하였다. 원인은 웹에서 생성한 유저와 EC2에서 사용하는 CLI 유저가 달라서 생긴 현상으로, 쉽게 해결하는 방법으로 웹페이지 로그인을 유저로 변경해서 로그인하여 생성하는 방식으로 해결했다. 다른 방식으로도 해결은 가능할테지만, 해야 할 일이 많아 생략한다.

오늘은 Kubenetes에 대해서 공부했고, 복습하며 내가 이해한 내용을 적어보려고 한다. 쿠버네티스, 도커, 컨테이너란? 쿠버네티스란 컨테이너 오케스트레이션 툴이다. 컨테이너란 호스트 OS에 논리적 구역(컨테이너)를 만들어, 어플리케이션 실행에 필요한 라이브러리 등의 리소스를 한데 모아 서버인 것처럼 실행시킬 수 있도록 만드는 것을 의미한다. 서버 구축에 필요한 자원을 최소한으로 사용할 수 있게 되고, 서버 구축에 필요한 개발 시간이 많이 단축되기 때문에 많이 사용되기 시작했다. 도커는 위의 컨테이너를 구축하고 관리할 있도록 이미지라는 단위를 이용해 컨테이너를 생성, 배포할 수 있게 해주는 소프트웨어이다. 하지만 컨테이너간 호환이나 컨테이너를 여러 개 관리하는 경우 관리의 어려움이 생겨 컨테이너 간 오..

1. Slack -> 앱 -> webhook 검색 -> Incoming Webhooks 검색 2. 알림을 전달할 채널 선택 3. URL 복사 후, json 데이터 형식으로 데이터 보내기 { "username": "TW", "text": "채널에 있는 한 줄의 텍스트입니다. \n또 다른 한 줄의 텍스트입니다.", "icon_emoji": ":ghost" } 테스트(Talend API Test Tool로 진행하였다.) 4. 결과 확인