1. 무엇을 하고 싶으신가요? cosign sign을 통한 이미지 스캔을 하고 싶은데 단순히 이미지 재빌드하고 푸시하면 해결될 것이라고 생각하는데 그러지 않고 해결할 수 있는 방법을 찾고 싶습니다. 2. 언제, 어떤 오류가 발생하시나요? cosign에서 맨처음에 태그 기반으로 사이닝을 진행(최초 --tlog-upload=false 옵션 없이 이때 따로 진행할거냐는 경고 없이 바로 사이닝 진행 , 이후 --tlog-upload=false 옵션과 함께 진행하였지만 이미 사인되어있다는 메시지 그리고 ECR을 확인해보니 레포지토리에 서명 결과가 푸시된 것을 확인) , 이후 서명 결과를 ECR에서 삭제하고 다이제스트 기반으로 sign 명령을 내려도 계속 409 에러가 발생합니다. 3. 어떤 시도를 해보셨나요? 4. 작성한 코드를 공유해주세요. cosign sign --tlog-upload=false \ --key awskms:///REDACTED-KMS-KEY-ID \ <AWS_ACCOUNT_ID>.dkr.ecr.<REGION>.amazonaws.com/<REPO>@$( docker buildx imagetools inspect \ <AWS_ACCOUNT_ID>.dkr.ecr.<REGION>.amazonaws.com/<REPO>:latest \ --format "{{json .Manifest}}" | jq -r ".digest" ) Error: signing [<AWS_ACCOUNT_ID>.dkr.ecr.<REGION>.amazonaws.com/<REPO>@sha256:<DIGEST>]: signing digest: signing bundle: [POST /api/v1/log/entries][409] createLogEntryConflict {"code":409,"message":"an equivalent entry already exists in the transparency log with UUID <REDACTED>"}
만약에 협업을 진행하는 과정에서 제가 develop브랜치에서 feat1브랜치를 따서 작업을 한후 push한다음 pr을 만들었지만, 아직 merge되지 않은 상태에서 feat1 브랜치보다 늦게 다른 팀원이 feat2브랜치를 따서 작업을 해서 push한 후 pr에서 develop브랜치에 merge까지 된 상태인 경우. feat1브랜치 사용자는 git pull origin develop 해서 최신사항을 내려받은 후 남은 작업을 수행해야하는 것인지 궁금합니다. 또한 git pull origin develop한다고 가정했을 때, 커밋이력이 1개만 추가되는 것인지 develop 브랜치의 최신 커밋이력들을 전부 가져오는 것인지 궁금합니다.
안녕하세요 강사님 main 브랜치를 최상위 브랜치로 놓고 거기서 하위 브랜치인 dev 브랜치가 나오고 dev 브랜치에서 이걸 상위 브랜치로 갖는 다른 브랜치를 만드는 방법이 있나요? 로컬에서 여기서 설정 하는 거 말고 혹시 다른 방법이 있나요? 여기서 만들고 계속 동기화해서 올리고 있습니다.
우선 좋은 강의 만들어주셔서 정말 감사드립니다. 이번에 새로 출시된 강의 " eks를 활용한 spring 운영서버 배포(feat. devops의 모든것)" 이 강의 질문 할 곳이 없어서 여기다가 질문을 드립니다. 양해 부탁드립니다. 제가 쿠버네티스 지식이 없다보니 질문 드리는 건데요. 해당 강의 경우 무중단 배포 로 진행 되는 강의 인지 궁금 합니다. 아무래도 실전에서는 무중단 배포로 진행 해야 하는 경우 많아서 이렇게 질문 하네요. 감사합니다.
git push origin main 명령어 실행 시, src refspec main does not match any 오류 발생하여 해결 방법 문의 드립니다. Config 로 유저네임과 이메일 설정해도 동일합니다. git branch 명령어 실행해 보면 브런치가 아예 없습니다. 선생님은 자동 생성돼서 최초 커밋을 main에 하셨는데 저는 왜 자동생성이 안돼서 브런치 생성을 따로 해야되나요?
브랜치 상황이 원격에 dev, feat/member 가 있고 로컬에도 dev, feat/member가 있다고 하겠습니다. 이때 제가 로컬 feat/member 브랜치에서 작업 중인데 원격 dev 브랜치에 있는 작업 내용을 제가 작업 중인 로컬 feat/member 브랜치로 가져오려면 어떻게 해야 하는지 궁금합니다.
vs code에서 깃 커맨드를 쓰거나 소스 컨트롤 기능에서 내역을 확인할 수 있는데 깃 GUI프로그램으로 소스트리를 따로 쓰시는 이유가 뭔가요? 그리고 깃헙 데스크탑 GUI프로그램이 있는데 깃헙 연동으로는 이게 더 편리할 거 같은데 소스트리가 더 우수한 이유가 있을까요?
rebase 시, 충돌이 발생했을때 관련해서 질문이 있습니다. master 의 commit이 만약 이렇게 되어있다면, (master) commitID_4-2 # test1.txt 수정 commitID_4-1 # test1.txt 수정 commitID_3 commitID_2 commitID_1 그리고 feature/rebase의 브랜치의 commit이 이렇게 되어있다면, (feature/rebase) commitID_4-4 # test1.txt 수정 commitID_4-3 # test1.txt 수정 commitID_3 commitID_2 commitID_1 여기서 feature/rebase 브랜치에서 master를 rebase를 하려고 한다면, 4-1, 4-2도 test1.txt를 수정했고, 4-3, 4-4도 test1.txt를 수정해서 conflict이 발생한다면, 그래서, rebase를 만약 해본다면 git checkout feature/rebase git rebase master 여기서 conflict이 발생하고, 그걸 해결하게 된다면 # conflict 발생 후, 수정 git add test1.txt git commit -m "conflict1" git rebase --continue git add test1.txt git commit -m "conflict2" git rebase --continue >> resolved conflict ... 이렇게 모든 conflict를 수정한 다음에 여기서 어떻게 처리할지 질문입니다. 여기서 제가 git push origin feature/rebase 를 하게된다면, 원격저장소와 로컬저장소의 commit이력이 달라서 다시 git pull origin --rebase feature/rebase 후, 다시 conflict를 수정하고 새로운 commit을 만들어서, push를 하는게 맞는건지 여기서 어짜피 모든 conflict를 해결했으니 git push origin feature/rebase -f 로 강제로 밀어 넣던지 아니면 다른 방법으로 push를 하는건지 보통 rebase시, conflict이 발생 후, conflict를 해결하더라도 push 시, 로컬/원격 저장소간의 commit이력이 달라질텐데 이것을 해결하기 위해 어떤방법을 사용하는지 궁금합니다.
가이드주신 대로 GitLab 세팅 후 nestjs-boilerplate development 브랜치로 commit & push했으나 위 사진과 같이 test 스테이지까지만 진행되고 development를 포함한 이후 스테이지들이 진행되지 않습니다... 놓친 부분이 무엇일까요??
안녕하세요. 이번에 public subnet 에 있는 bastion host를 통해서 private subnet에 있는 web server라는 ec2에 cli 명령어로 gitlab ee 버젼을 설치해서 도메인(a.test.com)으로 설정하였습니다. 그런데 sudo vi /etc/gitlab/gitlab.rb 파일에 bastion host의 public ip를 넣어야 도메인으로 gitlab server의 사이트로 접속이 되던데.. 이러면 public ip가 그대로 노출될 수도 있어서 도메인으로 바꾸면 사이트의 접속이 막히고 있습니다. 도메인으로 설정을 바꾸면 어떻게 해야하나 질문을 드립니다. CI/CD 과정은 리포지토리는 Gitlab, 빌드과정은 codebuild를 사용하려고 합니다. codebuild와 연결을 할때도 액세스 토큰이 필요해서 이부분은 어떻게 설정해야 하나요?
Load Banacer Controller 설정 과정 중 eksctl create iamserviceaccount \ --region ${region} \ --name aws-load-balancer-controller \ --namespace kube-system \ --cluster ${clusterName} \ --attach-policy-arn ${policyArn} \ --override-existing-serviceaccounts \ --approve 을 실행하면 1 existing iamserviceaccount(s) (kube-system/aws-load-balancer-controller) will be excluded 1 iamserviceaccount (kube-system/aws-load-balancer-controller) was excluded (based on the include/exclude rules) metadata of serviceaccounts that exist in Kubernetes will be updated, as --override-existing-serviceaccounts was set no tasks 위와 같은 로그가 출력되고 k get sa -n kube-system 을 실행하면 aws-load-balancer-controller가 나타나지 않습니다. NAME SECRETS AGE attachdetach-controller 0 111m aws-cloud-provider 0 111m aws-node 0 108m 어떤 원인인지 알수 있을까요?
