본문 바로가기

분류 전체보기

 (285)
develop 추적하는 feature 브랜치 만드는 명령어 origin/develop을 바라보는 feature 브랜치를 생성하는 명령어이다. git checkout -b local-branch-name —track origin/develop local-branch-name에 내가 만든 feature 브랜치 이름을 넣어준다. 그러면 branch 'feature/support-for-merge' set up to track 'origin/develop'. 새로 만든 'feature/support-for-merge' 브랜치로 전환합니다 라는 문구가 뜬다. * git log를 통해 해당 브랜치가 origin/develop을 잘 바라보고 있는지 확인 필요 (HEAD -> feature/support-for-merge, origin/develop)
git 병합 중단 방법(커밋 날리지 않았을 때) develop > stage로 merge를 하려고 하니 그전에 PR을 날려야 할 것 같았다. 그래서 이걸 중단하고자 했는데 방법을 찾아보니 다음과 같이 진행해주면 된다. * Commit을 날리지 않은 상황이어야 한다. develop > stage로 병합하려던 중에 병합 충돌이 났던 코드들을 merge 하는 도중에 이 과정을 중단하고 싶어 git merge --abort를 해주었다. 그러면 지금까지 변경했던 코드들이 다시 제자리로 되돌아가고, stage에도 Resolve하거나 커밋을 날려야 하는 이력들은 사라지게 된다. 이로써 merge 중에 중단이 가능하다.
파이프라인에 배포 완료했는데 다시 배포 rollback 하는 방법 with kubectl stage 환경 배포 파이프라인을 Build -> Deploy까지 아무 문제 없이 끝냈는데 막장 stage 환경 사이트에서 내가 배포 나갔던 부분이 500,503 에러를 내뿜고 있었다. 이를 다시 rollback을 해줘야 했는데, Build가 되고 Deploy 하는 중에는 배포를 Cancle 할 수 있는 버튼이 활성화 되어있었으나, Deploy가 끝나고 난 후에는 Cancle을 할 수 있는 버튼조차 없었어서 멘붕이 왔는데 알고보니 kubectl rollback 명령어로 해결할 수 있었다. 해결 방법 kubectl rollout history deployment -> 배포 나간 파이프라인의 history를 확인한다. 여기서 버전(REVISION)이 여러 개 보인다. ** 버전의 상세 내역을 보려면 kube..
yaml 파일에 대하여 데이터를 표현할 수 있는 형식에는 3가지가 있다. 흔히 볼 수 있는 JSON 파일, XML, 그리고 Yaml 파일이 있다. 흔히 야믈 파일이라고 부른다. Yaml 파일의 어원은 Yaml Ain't Markup Language 라는 뜻으로, Yaml 파일은 마크업 언어라는 뜻이 담겨있다. 데이터를 나타내는 언어이기 때문에 마크업 언어가 아니라는 것을 나타낸다. Docker 파일이나 Kubernates를 사용할때 yaml(또는 yml) 파일을 접하게 되는데, yml 파일은 데이터를 직렬화로 나타낸 파일이라고 보면 된다. yml 파일의 List 형태 yml 파일은 타 시스템 간의 데이터를 주고받을 때의 문법을 중요시 여긴다. 가독성은 좋은 것 같다. Key-Value쌍으로 구성되어 있으며 띄어쓰기로 데이터를 ..
kubectl로 pod 생성 & 확인하기 Pod는 kubernates에서 가장 작은 단위이다. 이 pod를 kubectl로 생성하기 위해서는 다음과 같은 과정을 거친다. 1) kubectl run nginx --image=nginx -> 이름이 nginx인 pod를 생성한다 * 이미지는 도커 허브나 다른 컨테이너에서 사용할 수 있는 이름이어야 한다 2) kubectl get pods -> pod가 만들어진 리스트를 볼 수 있다. 이는 실행중인 pod들이다. 3) kubectl describe pod nginx -> 1)번에서 만든 nginx pod에 대한 자세한 설명을 터미널에 출력해서 보여준다. 추가) kubectl get pods -o wide -> 터미널에 좀 더 넓게 출력되는데 실행중인 pod들의 리스트를 좀 더 상세하게 볼 수 있다.
로컬 큐와 클러스터 큐 구분 (with dev,prod) RabbitMQ를 사용하고 있는데, local로 queue에 접근하는 방법과(개인 테스트용) + cluster로 접근하는 방법이 있다. 주로 자신이 개발한 것을 테스트 하기 위해서는 local queue로 접근을 하는데, 분명 local queue로 접근을 했다고 생각했지만 잘못된 행동을 하고 있었다. local queue여도 dev, prod 구분 필요 dev와 prod의 EXTERNAL-IP 주소가 다른데, 나는 dev를 실행하고 있는데 prod 환경의 queue를 실행하고 있었다. 그런데, 이는 엄청 위험한 짓이다. prod 환경에 dev의 queue 내용이 쌓일 수 있다는 어마무시한.. 일이 벌어질 수 있다는 것이다. prod queue가 아닌 dev queue로 접속하기 위해 다음과 같은 과정..
Error: Your application tried to access @eslint/eslintrc, but it isn't declared in your dependencies; this makes the require call ambiguous and unsound. yarn > pnpm으로 바꾸게 되면서 pnpm에서 ESLint까지 적용을 했다. 1) brew install pnpm 2) pnpm install 3) pnpm run lint를 했는데 아래와 같은 에러가 계속 발생하였다. Oops! Something went wrong! :( ESLint: 8.55.0 Error: Your application tried to access @eslint/eslintrc, but it isn't declared in your dependencies; this makes the require call ambiguous and unsound. Required package: @eslint/eslintrc ~ package.json과 pnpm list로 여러 lint 버전을..
fatal: (현재 폴더 또는 상위 폴더 중 일부가) 깃 저장소가 아닙니다: .git 갑자기 상위 폴더로 어쩌다 이동이 되었는지.. 다시 클론받은 repo 이름 git:(feature/popup-refactoring) 으로 이동하기 위해서 상위 폴더로 이동을 했는데 fatal: (현재 폴더 또는 상위 폴더 중 일부가) 깃 저장소가 아닙니다: .git 와 같은 에러가 뜨는 것이다. 그래서 구글링을 해서 git init을 해야 하나..? 싶었는데 내가 만든 프로젝트 레포지터리가 아니라서 선뜻 git init을 할 수 없었다. 알고보니, 다음과 같은 상황이었다. Desktop > 클론받은 레포지터리 이름 (.git 없음) Desktop > be > 클론받은 레포지터리 이름 (.git 있음) 이렇게 내가 이전에 2개로 클론을 받았었는데 .git이 없는 걸로 디렉터리 이동을 하고, git 명령어..
Kubernates + Docker 알아보기 ※이 글은 brandy가 개인적으로 공부하고 작성한 글이므로, 맞지 않는 내용이 있다면 피드백 부탁드리겠습니다. Kubernates를 공부하기 전에, Docker을 먼저 알아야했다. Docker은 그림과 같이 고래가 컨테이너를 싣고 있는 모습을 가진 깜찍한 아이콘을 자랑하는데, Docker은 애플리케이션을 Container로 실행하고 관리하는 오픈소스 플랫폼이다. 개발된 응용 프로그램(API 등)을 Container화해 운송하고 실행하는 것이 주 목적이다. Docker Container은 다음과 같은 특징을 가지고 있다. - 크기가 보통 MBytes여서 부팅이 빠르다. - VM같은 가상컴퓨터의 경우 부팅이 몇 분 걸리는데(OS나 커널에 의존하지 않음) 도커는 부팅이 빠르다. Docker은 Code, Bu..
hotfix 브랜치를 삭제하고 싶었는데 안되었던 문제 Live 환경에서 문제가 있는 것 같아 hotfix 브랜치를 따서 작업을 하려고 했더니, 코드 상의 문제가 아닌 db상의 문제였어서 db 테이블 내 데이터 값만 수정하였다. 그래서 hotfix 브랜치가 필요 없어서 삭제하려고 git branch -d 으로 브랜치 삭제를 하려고 했더니 브랜치 삭제가 되지 않았다. error '/PC경로/'위치에 체크아웃한 '브랜치명' 브랜치를 삭제할 수 없다는 에러가 표시되었는데, 알고보니 해당 브랜치에서 해당 브랜치를 삭제할 수 없다는 것. 맨 위 사진을 보면 현재 브랜치의 위치가 hotfix/popup_activeList인데, 현재 checkout된 브랜치가 hotfix/popup_activeList 브랜치다. 즉 이 브랜치에서 직접 hotfix/popup_active..

티스토리툴바