플래티어의 X2bee 솔루션은 develop 부터 production 레벨까지, 최적의 개발 환경을 위해 무중단 배포를 지원합니다.무중단 배포무중단 배포란 말 그대로 신규 배포시 서비스가 중단되지 않도록 배포하는 기술이다.다시 말하면 서비스하는 application을 내리지 않고, 새로운 application을 올리는 것이다.이와 관련해 두 가지 종류가 있다.하나는 배포 전략에 관련된 것이다.신규로 배포를 하고 그 pod가 정상적으로 동작을 하면 서서히 트래픽을 이 신규 pod로 흘려보내는 측면에서 보는 무중단 배포인데, 이것은 Blue/Green 배포, Canary 배포, 우리가 선택 중인 Rolling Update가 여기에 해당한다. (배포 전략에 대해 정리가 잘 된 블로그: https://onlyw..

CDN 구성의 이점빠른 응답 속도 - 여러 서버에 콘텐츠를 배포하여 배포 지연시간을 최소화무중단 배포 - 정적 파일을 CDN에 저장하여 새 버전 배포 시에도 서비스가 중단 되지 않음서버 부하 감소 - 정적 리소스를 CDN이 제공하므로 서버 부담이 줄어듬캐싱 활용 - 반복 요청에 대한 응답 속도가 빨라지고 비용이 절감됨 배포전략, 파이프라인에서 CDN 관리 하는 방법별달리 특별한 방법이 있는건 아니고, 기본 아키텍처를 이해를 하고있어야 작업 포인트를 잡을 수가 있습니다.지금 관리하고 있는 프로젝트의 아키텍처 기본 구성은 아래와 같습니다.소스관리 깃프로젝트CI/CD 파이프라인 관리 젠킨스배포 환경 KubernetesCDN 관리 FTP로 정적 파일 배포 젠킨스 파이프 라인에서의 구성 및 워크플로 젠킨스 파이프..

이 글은 Rocky Linux와 같은 Red Hat 계열 운영 체제에서 Kickstart를 사용해 자동화된 무인 설치 환경을 구성하는 방법입니다. 최종목표는 Kickstart 템플릿을 작성 & Ansible에 결합하여 효율적인 환경을 구성하는 데 목적을 두고 있습니다.다음 단계에서는 Kickstart 템플릿을 Ansible과 통합하여 동적인 값 설정과 대규모 배포 환경에 적용 방안을 다룰 예정입니다.KickstartKickstart는 Red Hat 계열의 Linux 배포판에서 무인 설치를 자동화 하는데 사용되는 파일 기반의 설치 방식입니다. Kickstart를 정의하여 일관성 있는 시스템 설치가 가능합니다.특히 Kickstart는 Infrastructure as Code (IaC) 환경을 구성할 때 유..

상처를 많이 받아 감정이 들어간 워딩이 많이 들어감. 화풀이식으로 작성한 글.프로젝트를 수행하는데 SMTP 이 간단한 장르로 한달이상 애를 먹었다. 해서. 비슷한 일이 발생하면 빠르게 대응하기 위해서 이력과 기록물을 남긴다. 이는 보통의 수행 레벨에서 정보(부정확한)만을 가지고 해결하기 위한 혼자만의 처절한 싸움이며 해결 솔루션을 도출하기 위한 노력이다.첫번째 기본 정보SMTP를 진행하는데 전달 받은 내용은 고작 해봐야 아래와 같은 정보였다.smtp server : abc.smtp-domain.comsmtp port : 25smtp user : sendersmtp password : pw-samplesmtn sender : sender@domain.com 첫번째 허들이었다. 잘못된 정보.위와 같이 내용..

개요내가 여기 입사하기도 전에 AWS EC2 instance에 설치되어있던,그리고 현재 개발용으로 사용중인 Gitlab은 버전 13.10.5이다.2021년 6월 버전이다.고작 3년밖에 안 되었지만 gitlab 생태계에는 고물 버전에 가깝다.최신 버전으로 업데이트 요청사항이 있었다.얼핏 드는 생각은Postgresql 마이그레이션 할 때처럼기존 configuration과 data dump 떠놓고최신 이미지로 docker container 올리고 데이터 이관시키면 된다고 생각했다.그러나 시행착오 끝에 이 방법은 통하지 않는다는 것을 알았다.이 방법은 똑같은 버전으로 다른 곳에 이관시킬 때나 써먹는 방법이다.그 이유는 major 버전 뿐만 아니라 minor 버전도 data 이관시안에 여러가지 복잡한 컴포넌트들(..

목차[1. 작업배경][2. 이관 전략][3. gitlab 미러링][4. 결론] 1. 작업배경내부에서 개발하고 있던 api 깃프로젝트 소스가 있었는데, 별도의 TF 프로젝트가 발생하였고 이에 따라 깃프로젝트 이중 작업이 불가피하여 TF 프로젝트용으로 api 깃프로젝트를 복제하여 새 구성을 하였습니다. 하여 내부적으로 api 깃프로젝트와 tf api 깃프로젝트가 생겨난 상황이었는데. api 깃프로젝트에서 진행된 내용이 tf api 깃프로젝트로 옮겨져야 하는 상황이 생겼습니다.이에 기존의 api 깃프로젝트를 A프로젝트로 가칭, tf api 깃프로젝트를 B프로젝트라고 가칭하여 브랜치를 이관하여 병합 관리하는 단계를 작성해보았습니다. 대상 프로젝트A 프로젝트 release 브랜치B 프로젝트 main 브랜치2. 이..