블로그 작성에 너무 힘 쓸 필요는 없다는 말씀이신가요?

안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해 주신 내용에 대해 답변드려볼게요 ! 결론부터 말씀드리면, 학생분의 생각처럼 본인을 위해 편하게 작성하시는 것을 권장드려요 !블로그에 너무 많은 시간을 투자하면 정작 중요한 실력 향상에 쓸 시간이 줄어들기 때문이죠 !면접관 입장에서도 블로그를 꼼꼼히 읽어보는 경우는 생각보다 드물고,오히려 포트폴리오 프로젝트나 기술 면접에서의 답변을 더 중요하게 봐요 ! 화려하게 꾸미거나 남에게 잘 보이려고 문장을 다듬는 데 시간을 쓰기보다는,핵심 내용을 간결하게 정리하고 그 시간에 한 줄이라도 더 코딩하시는 게 실력 향상에 훨씬 도움이 돼요 !다만 한 가지 팁을 드리자면, 트러블슈팅 경험이나 기술적 의사결정 과정을 담은 글은면접에서 실제로 도움이 될 수 있으니, 그런 내용은 조금 더 신경 써서 정리해두시면 좋아요 !하지만 이것도 완벽하게 작성하려고 하기보다는 일단 빠르게 기록해두고,나중에 필요하면 다듬는 방식으로 접근하시면 돼요 :) 추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요~~

안녕하세요 질문 있습니다.

안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해 주신 내용에 대해 답변드려볼게요 !결론부터 말씀드리면, 스프링 부트에서 Elasticsearch 라이브러리를 사용하면서 실제 서버는 OpenSearch를 띄워서 사용하는 것은 가능하지만 주의가 필요해요 !OpenSearch는 Elasticsearch를 개발한 회사가 2021년 1월 이후로 새로운 라이선스를 부과하면서 자유로운 활용이 금지되자, AWS가 이에 반발해 오픈 소스로 활용할 수 있었던 Elasticsearch 7.10.2 버전을 포크해서 만든 검색 엔진이에요 !대부분의 기능은 비슷하지만 OpenSearch와 Elasticsearch는 엄연히 다른 소프트웨어이고, 시간이 흐르면서 버전이 업데이트됨에 따라 기능이나 사용법의 차이가 조금씩 생기게 됐어요 !따라서 Spring Data Elasticsearch와 OpenSearch 조합으로 사용하실 경우, 기본적인 CRUD나 간단한 검색은 동작할 수 있지만 고급 기능에서 문제가 생길 수 있고, AWS OpenSearch에서는 nori 플러그인을 제공하지 않는 등의 차이도 있어요 !그래서 OpenSearch를 사용하실 거라면 spring-data-opensearch 라이브러리를 사용하시는 것을 권장 드리고, Spring Data Elasticsearch를 사용하실 거라면 Elasticsearch 서버나 Elastic Cloud 사용을 권장드려요 :)추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~

로드밸런싱 Server ID 출력에 관한 질문

안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해 주신 내용에 대해 답변드려볼게요 !"위 코드에서는 사실 서버는 1대이고, 포트번호만 8080과 8081로 로드밸런싱한 것 아닌가요?"-> 네 맞아요! 물리적으로는 1대의 EC2 서버에서 Spring Boot 애플리케이션 2개를 서로 다른 포트(8080, 8081)로 실행시킨거예요 !"실제로 서버 2대로 로드밸런싱을 하려면 localhost:8080과 localhost:8081 자리에 서버 도메인 주소가 들어가면 되는 건가요?"-> 네 맞아요 ! localhost 대신 각 서버의 IP 주소나 도메인을 넣어주시면 돼요 !"제가 말한 것이 맞다면 /health에 요청할 때마다 나타나는 Server ID는 같아야 하는 것인데, 왜 다르게 나오는 건가요?"-> Server ID는 물리적 서버를 구분하는 게 아니라, 각 Spring Boot 애플리케이션(프로세스)을 구분하는 값이에요 !8080 포트와 8081 포트에서 실행되는 Spring Boot 애플리케이션은 각각 독립적인 프로세스에요 !각 애플리케이션은 별도의 JVM에서 실행되고, 별도의 메모리 공간을 가지며, 별도의 Server ID를 생성해요 !그래서 /health 엔드포인트를 호출할 때마다 Nginx가 8080과 8081로 번갈아가며 요청을 보내기 때문에, 서로 다른 Server ID가 반환되는 거예요! 이게 바로 로드 밸런싱이 제대로 작동하고 있다는 증거에요 :)추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요 ~

도커 허브에서 postgres 버전 확인하는 법

안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해 주신 내용에 대해 답변드려볼게요 !"도커 허브에 있는 postgres:latest인데https://hub.docker.com/layers/library/postgres/latest/images/sha256-c84595a367a3fe5a4d9dce011490da38c462190e6ac7afb7d2a4c49436c80656이건 postgres 몇 버전인가요?"-> 현재 postgres:latest는 PostgreSQL 18.1 버전이에요!해당 링크의 Layers 섹션에서 확인할 수 있어요 ~Ctrl + F로 'PG_MAJOR' 와 'PG_VERSION'를 검색해 보시면 아래의 버전 정보를 확인할 수 있어요 !ENV PG_MAJOR=18ENV PG_VERSION=18.1-1.pgdg13+2여기서 PG_MAJOR=18이 PostgreSQL 메이저 버전이고, PG_VERSION=18.1-1.pgdg13+2가 정확한 버전 정보에요 :)"newest는 postgres:14.20-alpine3.23인데, 이건 14 버전인가요? "-> 네 맞아요 ! 14.20이 PostgreSQL 버전이에요 !newest는 "가장 최근에 push된 이미지"를 의미해서, 꼭 최신 버전이 아닐 수 있어요! 그래서 14 버전 이미지가 newest로 뜬 거예요 :)추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요 ~

보충 자료와도 관련된 추가 내용

안녕하세요 11 1님!! 수업 들으시면서 시행착오 겪으신 내용 공유해주셔서 감사합니다ㅎㅎ다른 수강생분들한테도 도움이 될 것 같네요!감사합니다~~~

mysql_data 폴더 내부에 다른 파일이 있는데도 잘 되는 경우

안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해 주신 내용에 대해 답변드려볼게요 !우선 "mysql_data 폴더 내부에 파일이 있으면 안 된다"는 것은 MySQL을 처음 실행할 때의 이야기예요 ! 그래야 MySQL 컨테이너 내부의 /var/lib/mysql 파일들이 호스트의 mysql_data 폴더로 복사되거든요 !하지만 이미 볼륨에 MySQL 데이터가 정상적으로 저장된 이후에는 컨테이너를 삭제하고 다시 생성해도 오류가 나지 않아요 ! MySQL 컨테이너는 새로 초기화하지 않고 기존 데이터를 그대로 사용하며 오히려 이게 볼륨의 목적이에요 ! 그래서 pwd1234로 바꿔서 컨테이너를 다시 생성했을 때 오류가 안 난 거예요! 이때 -e MYSQL_ROOT_PASSWORD=pwd1234로 새로운 비밀번호를 설정하더라도, 이미 초기화된 데이터베이스가 있기 때문에 이 환경변수는 무시돼요 ! 결과적으로 새로운 비밀번호 설정이 적용되지 않고 기존 비밀번호(password123)가 그대로 유지되는 거죠 🙂 즉, "폴더가 비어있어야 한다"라는 건 최초 1회 실행 시에만 해당되는 내용이고, 이후에는 기존 데이터를 재사용하는 게 정상이에요 !추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요~~

현업에서 MySQL은 RDS와 도커 볼륨 중 어떤 걸 사용하나요?

안녕하세요 11 1님! 질문 잘 해주셨어요~~~어느 정도 서비스의 안정성이 중요해진 기업에서는 AWS에서 제공하는 고가용성과 다양한 편리한 기능들 때문에Docker로 MySQL을 띄워서 사용하는 것보다RDS를 사용하는 경우가 많습니다:D이 외로 또 궁금한 점 있으시면 질문 남겨주세요~~

노션 자료에 안 보이는 이미지가 있습니다

안녕하세요 11 1님! 제보해주셔서 감사합니다ㅎㅎ말씀해주신 덕분에 안 보이는 이미지를 다른 이미지로 교체했습니다! 감사합니다:D

default.conf

안녕하세요 ! 질문 잘해주셨어요 !질문해 주신 내용에 대해 답변드려볼게요 ~이전에 해당 파일을 실수로 삭제했거나, 설치 방법 및 운영체제와 같은 서버 환경에 따라 기본 설정 파일 경로가 다른 경우 /etc/nginx/conf.d/default.conf 파일이 보이지 않을 수 있어요 !HTTPS 인증서가 정상적으로 발급된 상태라면, Nginx 설정 파일 어딘가에 # managed by Certbot이라는 주석이 반드시 들어 있어요!아래 명령으로 실제로 사용 중인 설정 파일을 확인해 보시는 걸 추천드려요 !sudo nginx -tsudo find /etc/nginx -name "*.conf"sudo grep -R "managed by Certbot" /etc/nginx이 명령을 통해 Certbot이 수정한 설정 파일의 정확한 위치를 찾으실 수 있고, 강의에서 설명드린 HTTPS 관련 코드는 경로만 다를 뿐 내용과 의미는 동일하니 그대로 이해하시면 돼요:)혹시 위 방법으로도 찾기 어려우시면 현재 어떤 경로에 어떤 파일들이 있는지에 대한 내용과 함께 언제든 편하게 추가 질문 주세요 ~~늘 파이팅입니다 😄

도커 허브에서의 latest가 가장 최신인 게 맞나요?

안녕하세요 ! 질문 잘해주셨어요 ! 많은 분들이 헷갈려 하시는 부분이에요 !질문해 주신 내용에 대해 답변드려볼게요 ~우선 Docker Hub에서 latest 태그는 가장 최신 이미지를 자동으로 가리키는 게 아니고 그냥 하나의 태그일 뿐이에요 !이미지 관리자가 "이 버전을 latest로 하자!"라고 수동으로 지정하는 거예요 ~말씀하신 것처럼 trixie-perl이 시간상으로는 더 최근에 푸시된 이미지가 맞아요 !하지만 이건 Debian Trixie 기반에 Perl 모듈이 포함된 특수 목적용 이미지에요 !반면 latest 태그는 대부분의 사용자들이 범용적으로 사용할 수 있는 안정적인 기본 버전을 가리키도록 관리자가 설정해놓은 거예요 !nginx 이미지 관리자 입장에서는 사용자들이 docker pull nginx 했을 때 가장 범용적이고 안정적인 버전을 제공하고 싶은 거죠:)그래서 시간상으로 최신은 아니더라도 가장 많은 사람들이 안전하게 쓸 수 있는 버전을 latest로 유지하는 거예요 !추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~