안녕하세요 강사님 해당 강의에서 headless service 통신 테스트를 해봤는데요 deployment + headless service 상황에서 pod내부에 아래 명령어를 했는데 찾지 못한다고하는데 nslookup [pod명].[svc명].[ns].svc.cluster.local 혹시 statufulset만 가능한건가요?
강의를 들으면서 프로젝트로 실습해보다가 궁금한 점이 생겨 질문드립니다! 강의에서는 main 브랜치에 push가 일어나는 것이 트리거가 되는 경우를 설명해주셨습니다. 만약에 main 브랜치 하위에 기능별로 브랜치를 나누어서 feature/login, feature/post 식으로 브랜치가 존재하며 프론트엔드 React 코드, 백엔드 Spring 코드의 별도 구분 없이 각각의 브랜치에 같이 존재한다면 백엔드 코드만 ec2에 deploy 되도록 설정하는 방법이 있을까요?
안녕하세요. CICD강의 잘보고있습니다. [실습] 컨테이너 기반 + 확장성을 고려한 프로젝트에서 많이 쓰는 CI/CD 구축 방법 까지 잘 진행해서 배포까지 완료했습니다. scripts > start-server.sh 에서 질문이 있는데요 docker pull {ECR Repository 주소} /instagram-server:latest 여기서 에러가 나서 정상적인 docker image를 pull받지 못합니다. 제가 작성한 코드입니다. docker pull {EC2소유자}.dkr.ecr.ap-northeast-2.amazonaws.com/github-actions:latest 발생 에러 코드입니다. [stderr]Error response from daemon: Head " https:// {EC2소유자} .dkr.ecr.ap-northeast-2.amazonaws.com/v2/github-actions/manifests/latest ": no basic auth credentials 감사합니다.
"이름 때문에 기대가 너무 컸던 Secret" 강의 내용에 대한 질문 입니다. secret type 중 docker-registry 를 소개해주셨는데 공식 문서에서 해당 타입을 사용하는 예로 써 kubectl 명령어를 이용한 생성에 대한 언급만 있습니다. docker-registry 유형은 yaml 로 생성하여 사용 가능한것인지가 궁금합니다 ..! cafe: https://inf.run/X6Tbp
안녕하세요. 재밌고 좋은 강의를 해주셔서 감사합니다. 아직 70%정도 보고 있지만 궁금하게 있습니다. 현재 백엔드 개발자로 근무하고 있는데 저희 환경은 aws의 ec2에 직접 올려 백엔드 서버(spring-boot)를 운영하고 있습니다. 점차 쿠버네티스 환경으로 변경하려고 인프라담당자들과 백엔드 개발자들이 스터디 및 환경 구축하고 있는데요. 만약 실무에서 쿠버네티스 환경으로 바뀐다면 개발자들의 로컬 개발 환경은 어떻게 하시는지 궁금합니다. 대부분 자바, 스프링 환경이면 인텔리제이등으로 개발 후 테스트를 해볼텐데 컨테이너에서 다른 개발자들과 다 같은 환경에서 테스트를 해보고 빌드해보고 해야 하지 않는가 싶어서요. 실무에선 어떤식으로 개발자들이 개발하는지 개발, 테스트 , 운영 배포 까지 플로우가 어떻게 되는지 궁금합니다.
안녕하세요! 도커의 사용목적에 대해 알고싶습니다. 도커가 편리한 이유는 여러 프로그램을 한 대의 컴퓨터에서 실행시킬 수 있기 때문이라고 이해하였습니다. 그런데 만약 서버 한 개만 돌릴 때는 도커를 사용해야 할 필연성이 있을까요? 단순히 확장성 떄문에 사용하는 건가요? 왜 써야 하는지 잘 모르겠습니다..
안녕하세요 강사님, 현재 강의를 참고하여 팀원끼리 클론 코딩 프로젝트를 하기위해 EC2에서 Spring Boot + MySQL 서비스를 Docker Compose로 구성하여 배포 중입니다. GitHub Actions를 통해 ECR에 푸시한 Spring Boot 이미지를 EC2에서 pull 받아서 docker-compose로 실행하는 파이프라인을 구축했습니다. 현재까지 진행한 작업에 대해 말씀드리겠습니다. Spring Boot 애플리케이션을 Dockerfile로 빌드해 Amazon ECR에 업로드 EC2에 MySQL과 Spring Boot를 각각 컨테이너로 구성 ( docker-compose.yml 사용) GitHub Actions에서 EC2로 SSH 접속 후 .env 생성 및 docker-compose up -d 자동 실행 설정 현재 EC2 인스턴스(t2.micro)에 연결이 실패하고있습니다. ssh -v -i를 통해 로그를 확인 해본 결과 연결은 성공하지만 인증 전 또는 핸드쉐이크 중에 connection reset 이 발생하였다고 합니다. 현재 인스턴스 유형은 t2.micro이며, Docker로 2개 컨테이너가 실행 중이었습니다. CPU/RAM 자원이 부족해 SSH 연결도 거부되는 것 아닌가 의심됩니다. 혹시 이 경우 인스턴스 유형을 업그레이드를 하는게 해결방법일지 혹은 다른 방법이 있을까요?
강의중 파드가 5개인데..처음에 2개가 생성되는건 maxSurge 25% 5개 파드의 25% 여서 2개인건가요? 그런다음에 왜 maxUnavailable 25%에 대해서는 2개 삭제가 아닌 1개만 삭제되는지도 이해가 안되구요 같은 25%인데요... 그럼 그상태에서는 4개만 서비스가 되는건가요? 아니면 추가로 생성된 2개도 서비스가 같이 되고있는건가요? 그럼 총 6개가 서비스되고 있는상태에서 또 몇개가 생성되고 몇개가 죽나요? 이게 일단 기동시간이 같다는 전제하에 블루그린방식과 같다는게 좀 이해가 안갑니다. 새로 올라온 서버는 서비스가 안되는건가요?
중요하다고 생각해서 여러번 보는데도 api입장에서는 이해가 잘 안되네요..제가 생각한 결론은 liveniessProbe는 pod재기동을 위한 api 상태체크같고 readinessProbe는 service에 pod를 연결시킬거냐 말거냐를 결정하는거 같은데... 이걸 호출하는 api 를 봤을땐 liveness와 readiness의 api를 실무에서 어떻게 각각 구별해서 만들수가 있을까 싶은거에요... 또한 app초기화 user초기화로 구분했던것도 실은 서버가 올라옴과 동시에 거의 강사님이 말씀하신 app초기화와 user초기화는 거의 순식간에 끝나는거 아닌지요? 막말로 톰캣서버올라오는 순간 모든 api들은 정상호출되는거 아닌지요..그리고 그렇게 user초기화를 위한 과정이 서버 기동시 그렇게 오래 올라올까 싶기도 하고..만약 실제로 그렇다면 굳이 startupProbe가 왜 필요할까 싶기도 해요...어차피 startupProbe가 성공하던 말던 중요한건 readiness에서 서비스연결할지 여부를 결정할거고 liveness에서 재기동까지 결정할텐데..굳이 startupProbe까지 넣을필요있는지.....설명은 이해가 되지만 실제로 의미가 있을까 하는 생각뿐이에요..