잡다한 이야기

aws의 eks를 활용해 백엔드 서버 배포 파이프라인을 구축 하는 방법에 대해 정리 하고자 한다. test용 서버 같은 경우엔 https가 필요 없을수도 있겠지만, 여기서는 http, https 프로토콜 통신이 가능한 배포를 가정하고 진행하도록 하겠다.(https때문에 많은게 복잡해짐) 1)aws cli 프로그램 설치 2)aws configure 명령을 통해 AWS CLI를 설정. AWS Access Key ID, AWS Secret Access Key, Default region name 등 3)kubectl 설치 및 helm설치 1.eks 클러스터 생성 1)버전, 이름 등 선택 2)iam역할 : awseksclusterrole 선택 3)별도 암호화 선택 없이 진행 4)VPC, subnet, 보안그룹..

igw가 붙은 외부인터넷용 VPC와 igw가 없는 내부용VPC 구성을 일전에 설명한 바 있다.(참고:https://severalpg.tistory.com/90) 내부용 VPC라 하더라도, 외부로의 outbound 인터넷은 대부분의 경우 필요하다. outbound인터넷을 하려면 nat게이트웨이가 필요할텐데, nat게이트웨이는 public한 subnet에 구성되어야 한다. 즉, public서브넷이 구성 가능한 VPC와 내부 private VPC와의 연동이 필요하다는 것이다. 여기서는 Transit Gateway를 사용할 것이다. 이와 관련된 AWS공식 문서가 있으니, 시간적 여유가 있다면 공식문서를 꼼꼼히 읽어보고 시간이 없다면 이글에서 간단히 어떻게 구축하는 것인지 참고용으로 보면 되겠다. 참고)공식문서 ..

일반적인 AWS 웹서비스 서버프로그램 구성 절차(public/private 서브넷) 1)VPC를 생성한 뒤에 igw를 생성하여 VPC에 연결 2)public용, private용 서브넷을 각각 구성 3)public/private용 라우팅테이블을 각각 만들어, public 라우팅테이블에는 igw를 라우팅시키고 public서브넷에 연결을시키고, private용 라우팅테이블에는 nat 게이트웨이 및 로컬사설IP만 라우팅 설정. private서브넷에서도 패키지 download, 외부서버와의 통신 등의 이유로 outbound 인터넷 통신이 필요하기 때문에 nat사용. 4)nat 게이트웨이 생성시 외부에서 IP인식될 IP를 할당하기 위해 EIP(고정IP)생성하여 연결. 또한 nat는 인터넷환경이 가능한 public서..

이 글에서는 alb의 로드밸런싱 역할보다는 ecs를 통해 ec2로 컨테이너를 배포할때 health check를 어떤식으로 하게 되는지는지와 이때에 각각의 서비스의 역할이 무엇인지 위주로 살펴보도록 하자. 클러스터 생성 ecs를 통해 클러스터를 생성시에, 아래와 같이 Auto Scaling 그룹을 선택할 수 있게 된다. 오토스케일링 그룹을 통해서 ecs를 통해 배포할 인프라를 결정하게 된다. AutoScaling그룹에서 CloudFormation 스택을 통해 배포할 인프라가 잡혀 있으면, ecs에도 해당 인프라를 배포대상 인프라로 잡게 된다. 서비스 생성 그 다음, 만들어진 클러스터에서 서비스 생성을 하여, 배포할 작업정의 패밀리를 선택하게 되면 alb 선택란이 활성화 된다. alb와 대상그룹을 연동시키려..

merge conflit 해결 - 명령어 현재 checkout된 dev브랜치에서 feature브랜치인 dev1브랜치를 merge시킨다고 하자. git merge dev1 dev브랜치와 dev1브랜치가 각 각 dev.txt라는 파일을 같은 라인을 다르게 수정했다. 이때에는 충돌이 발생한다. (만약 dev와 dev1dl 각각 dev.txt파일의 다른 라인에서 다른 내용을 수정했다면 이는 충돌이 발생하지는 않는다. 이때에는 git이 적절하게 merge를 시키기 때문이다.) Auto-merging dev.txt CONFLICT (content): Merge conflict in dev.txt Automatic merge failed; fix conflicts and then commit the result. 충..

여기서는 git으로 협업시의 merge, rebase, squash에 대한 차이와 merge전략에 대한 얘기를 하고자 한다. 현업에서는 회사마다 git branch전략이 제각각 이겠지만, 일반적으로는 develop(개발) -> release(운영)과 같은 형식으로 브랜치가 구성돼 있거나, 단일 main 브랜치로 운영이 된다 하더라도 협업을 할때에는 각각의 feature브랜치 만들어 작업후에 merge하는 과정을 거쳐 git에서 소스코드를 관리할 것이다. 예를 들어) 기능 추가/수정 시에 개발자들이 feature브랜치를 따서 개별적으로 브랜치에서 작업한 후에 develop으로 PR을 올린 이후에, 해당 PR을 merge하는 과정을 거치게 될 것이다. 충분한 테스트와 검증이 끝나면 develop에서 rele..

너무 기초적이고 자주쓰이는 명령어는 제외하였고, 종종 쓰긴하지만 헤깔리는 git 명령어 + 옵션을 위주로 정리 하였다. git init 등 git init 먼저, 새로운 저장소를 생성하는 명령어 이다. 저장소 정보가 담긴 .git 폴더가 생성이 된다. 일반적으로는 프로젝트 생성과 배포를 할때에 원격저장소와 연동을 해야 하기 때문에 아래와 같은 단계를 거친다. 프로젝트 생성 및 개발수행 -> git init -> github에서 repository 생성 -> git remote add -> git add . -> git commit -m "첫번째커밋" -> git push origin main 또는 아래와 같이 원격저장소를 먼저 만든 다음에 git clone을 통해 원격저장소 주소와 정보가 모두 담긴 fo..

(docker를 사용할때 종종 나오는 exec명령어, it옵션, /bin/sh등에 대해서 먼저 다루고, 글 하단에서는 개발자들이 빈번히 사용하는 docker 명령어에 대해 정리 했습니다.) docker exec :exec는 컨테이너ID뒤에 나오는 command를 해당 컨테이너에서 실행하라는 명령어. ex)docker exec alpine-test touch /tmp/execWorks : alpine-test이름을 가진 alpine리눅스 컨테이너에 /tmp 경로에 execWorks 파일을 만들라는(touch) 명령어 ex)docker exec -it 컨테이너ID /bin/sh(or /bin/bash) :-i옵션은 -interactive의 약자로서 c언어의 stdin(입력)을 open하라는 의미 :-t옵션은..

cron은 주기적으로 반복적인 작업을 리눅스에서 스케쥴링을 미리 지정하여 자동으로 실행되도록 하는 프로세스이다. 크론을 통해 db나 파일의 주기적인 백업, 패치작업, 파일용량 수시로 체크 등의 작업을 자동으로 수행할 수가 있다. cron의 데몬 프로세스 이름은 crond 이다.(데몬이 무엇인지는 여기 글 참고.) crond 데몬은 기본적으로 매분 마다 실행이 되면서, crontab파일을 스크리닝한다. anacrontab에 대한 내용도 알필요는 있으나, 여기서는 실질적으로 개발자들이 많이 활용하는 crontab을 자세히 알아보고자 한다. 먼저 리눅스에서 /etc/ 로 이동하여 ls -al 해보면 아래와 같은 폴더와 파일들이 있는 것을 알 수 있다. 이중 crontab 파일을 vi를 통해 열어 보면 아래와 ..

윈도우에서 주로 사용하는 개념인 서비스와 리눅스 등 유닉스 계열에서 사용하는 데몬은 완전히 같지는 않지만 유사하게 생각하면 될 것이다. 그래서 리눅스에서 service라는 단어가 보인다면, demon과 유사하게 생각해도 좋을것. 이 글은 개발자들을 위한 것이므로 리눅스를 기준으로 설명하도록 하겠다. 데몬 VS 프로세스 둘다 process는 프로세스이나, 데몬은 사용자가 아닌 시스템에서 제어하는 프로세스이고 보통은 시스템 기동과 함께 항상 백그라운드에서 수행되고 있는 프로세스라고 보면 된다. 다만, 사용자가 특정 프로세스를 데몬으로 등록하여 사용하겠다 하면 이 프로세스 또한 사용자등록 데몬이 된다. 이에 반해 프로세스는 사용자가 제어하는 실행단위이고, 시스템 기동과 함께 동시에 기동되지 않기 때문에 사용자..