EC2에서 ECR이미지를 pull하여 실행중에 exec /usr/java/openjdk-17/bin/java: exec format error 해당 오류가 계속발생합니다. dockerimage가 ec2의 arm64와 달라서 그렇다는 글도 있어 docker buildx build --platform linux/arm64 -t kube-ecr . 해당 명령어로 build하여 ECR에 push도 해보고 했지만 여전히 같은 오류가 발생합니다. 어떻게 해결해야할까요??
안녕하세요! Configmap과 Secret 기본 개념 강의를 보다가 궁금한 것이 생겨 문의 드립니다. 수업 자료 중 컨테이너 안에 볼륨 마운트 경로인 /usr/src/myapp/datasource/dev 안에 postgresql-info.yaml 이 생성되는 것으로 표시 설명하셨는, 실제로는 secret-datasource 마운트 경로인 secret-datasource에 있습니다. 볼륨 설정 중 "files"는 앱에서 사용할 볼륨을 설정하는 것이고, "secret-datasource"는 secret의 내용을 저장하는 볼륨으로 이해하면 맞는 걸까요?
안녕하세요. apt-get update에서 에러가 발생해 위의 정보를 참고하여 7번까지 수행한 후 9번을 수행하는 데 /proc/sys/net/bridge/bridge-nf-call-iptables does not exist 에러가 발생하였습니다. 어떻게 해결해야 할 문제인지 궁금합니다.
가이드주신 대로 GitLab 세팅 후 nestjs-boilerplate development 브랜치로 commit & push했으나 위 사진과 같이 test 스테이지까지만 진행되고 development를 포함한 이후 스테이지들이 진행되지 않습니다... 놓친 부분이 무엇일까요??
보안적으로 민감한 변수를 저장하기 위해 활용한다고 배웠습니다. 그러나 Secret의 작성 방법이 별다른 암복호화 로직없이 configMap과 99% 동일한 것 같아서요. 같은 repository에서 Secret과 ConfigMap가 함께 위치하는 경우 ConfigMap에 접근할 수 있는 사용자는 Secret에도 손쉽게 접근할 수 있을것 같다는 생각이 듭니다. Secret이 ConfigMap보다 어떠한 측면에서 보안상의 이점이 있는지 궁금합니다.
Pod 내부 API는 성공한다는 말이 User 초기화 상관없이 내부에서 성공하는 API를 말하는 것인가요 ? 외부 트래픽은 차단됐다는 말이 아직 User 초기화가 되지 않아서 외부 API는 차단이 되고, 이 상황에서 내부에서는 날리는 API는 실행되기 때문에 (App이 기동됐기 때문) 내부 API는 성공을 한다고 이해하면 될까요 ?
강의 영상 약 13:45초 부터의 내용에서 궁금한 점이 있습니다 위의 그림의 화살표 방향으로 jenkins 서버에서 다른 docker container로 ssh를 통한 접속을 시도할 때 접속 IP 주소로 내 로컬 PC의 IP주소:10022 로 접속하는 것과 우측 docker container의 IP 주소인 172.0.0.2:22로 접속을 시도하는 것의 차이가 있나요? 위 두 가지 경우 모두 접속이 가능하던데 두 경우의 차이가 존재하는지 궁금합니다!
안녕하세요! 우선 제 k8s cluster는 클라우드 서비스를 이용하여 master노드와 worker노드 2개를 각각 다른 vm에 설치해서 총3대로 구성한 상태이구요, section7의 service 실습 강의를 듣던 도중, master노드에서 DNS record를 조회해 보았는데 조회가 안되더라구요. 정상적인 결과인 것일까요? ps. 노드1에서 노드2로의 접근은 확인이 된 상태입니다. (pod-a가 node1, request-pod가 node2에 위치)
[질문 하기] 강의를 보다 livenessProbe가 killing하고 restart하는 기준이 이해가 안가서 질문 게시판을 봤는데, 저와 비슷한 의문을 가지신 분이 계신 것 같아서 질문드립니다. 일단 periodSeconds가 10초, 30초 모두 livenessProbe에서 실패를 하는데, 10초 설정은 killing을 하고 30초는 killing을 안 하길래 찾아보니 failureThreshold 라는 값이 또 있더라고요. 이 필드는 몇 번의 실패를 수신해야 실패로 간주하는지 설정하는 옵션입니다 (기본값: 3) . 이걸 보니 10초와 30초 옵션의 차이를 이해하게 되었습니다. 10초는 빠른 시간 내에 반복 체크해서 3번 실패하여 바로 실패로 간주하고 재시작하였고, 30초 옵션은 반복 2회차 이후에 pod가 정상적으로 떠서 3회차에 성공하여 pod를 재시작하지 않은 것 같습니다. 이외에도 다른 여러 옵션이 있지만 모든 옵션을 다루기에는 시간상 어려울 거라는 점은 이해합니다. 다만, 실습 환경에서 단순히 시간 차이로 테스트하는데 이러한 부분이 언급되지 않으면 이해하기 어려울 것 같습니다. 위 내용을 언급하지 않으신 특별한 이유가 있으신가요? 없다면 보충해주시는 게 좋지 않을까 조심스럽게 의견 드립니다.
안녕하세요 강사님 좋은 강의 감사드립니다. 강의를 보며 실습을 따라하여 hello-world.war 빌드 후 톰캣에 배포도 잘 되는 것을 확인하였습니다. jenkins는 도커를 이용하였고 톰캣은 제 local PC에 설치되어있는 것을 이용했는데 제가 궁금한 것은 젠킨스에서 빌드 후 제 로컬 PC 톰캣 webapps 폴더 밑에 hello-world.war 파일이 어떻게 생성된 것인지 그 원리가 궁금합니다. 톰캣 서버 실행 어플리케이션의 파일 위치 기본 설정이 webapps 폴더라서 그런걸까요? 젠킨스에서 어떤 설정을 참고하여 tomcat 서버 webapps 폴더 밑에 빌드 된 war 파일이 생성된 건가요? 혹시라도 질문이 이해가 안되신다면 알려주세요 감사합니다.
강의를 따라가다보니 java나 gradle, npm 등 개발 과정에서 쓰이는 명령어를 사용해서 이미지를 빌드하시는데 해당 cli들이 제 PC에는 설치가 되어있지 않아 실습을 하는데 따라가지 못하고 있습니다...ㅎㅎ 혹시 어떤 항목을 미리 설치를 해야하는지 리스트업 해주시면 설치해서 실습 따라가겠습니다...
http://127.0.0.1:52741로 접속해야 하는 이유는 다음과 같습니다: Docker 드라이버 사용: Minikube를 Docker 드라이버로 실행하고 있기 때문에, 클러스터의 네트워크가 호스트 시스템과 직접 연결되어 있지 않습니다 2 . 네트워크 격리: Docker 드라이버는 클러스터를 호스트 시스템과 네트워크적으로 격리시킵니다. 따라서 192.168.49.2와 같은 클러스터 내부 IP는 호스트에서 직접 접근할 수 없습니다 2 5 . 포트 포워딩: minikube service 명령어는 클러스터 내부의 서비스를 호스트 시스템의 포트로 포워딩합니다. 이 경우, WordPress 서비스의 80번 포트가 호스트의 52741번 포트로 포워딩되었습니다 8 . 로컬호스트 바인딩: 포워딩된 포트는 로컬호스트(127.0.0.1)에 바인딩됩니다. 이렇게 함으로써 호스트 시스템에서 해당 서비스에 접근할 수 있게 됩니다 9 . 터널링: minikube service 명령어는 내부적으로 터널을 생성하여 클러스터 내부의 서비스를 호스트 시스템에 노출시킵니다. 이 터널은 로컬호스트의 특정 포트(여기서는 52741)를 통해 서비스에 접근할 수 있게 해줍니다 1 8 . 따라서, http://127.0.0.1:52741은 Minikube가 생성한 터널을 통해 WordPress 서비스에 접근할 수 있는 주소입니다. 이 방식을 통해 Docker 드라이버를 사용하는 Minikube 환경에서도 클러스터 내부 서비스에 쉽게 접근할 수 있게 됩니다.