안녕하세요. 로컬 PC에서 elasticsearch를 도커 컨테이너로 구동하고 ( elasticsearch 8버전 ) python 프로젝트 ( python 3.11 버전 ) 는 로컬 ide에서 구동했을 때는 python 프로젝트 에서 --> elasticsearch 도커 컨테이너 까지의 https 요청이 정상적으로 수행되었습니다. 그런데 python 프로젝트를 컨테이너로 띄워서 elasticsearch 도커 컨테이너로 https 요청을 보내면 [ SSL routines:ssl3_read_bytes:sslv3 alert illegal parameter ] 이런 에러가 계속 발생합니다.python 프로젝트의 openssl 버전은 1.1.1w이고 elasticsearch 프로젝트의 openssl 버전은 1.1.1f 입니다. oepnssl로 디버깅 하기위해 openssl s_client -connect inspiring_noether:9200 -tls1_2 -CAfile ./http_ca.crt 를 실행하면 아래와 같이 출력됩니다.. 디버깅으로 보면 정상 통신으로 보이는데 어떤게 문제일까요,,?ㅠCONNECTED(00000003) Can't use SSL_get_servername depth=1 CN = Elasticsearch security auto-configuration HTTP CA verify return:1 depth=0 CN = a7cf2750c76a verify return:1 --- Certificate chain 0 s:CN = a7cf2750c76a i:CN = Elasticsearch security auto-configuration HTTP CA 1 s:CN = Elasticsearch security auto-configuration HTTP CA i:CN = Elasticsearch security auto-configuration HTTP CA --- Server certificate --- http_ca.crt 인증서 내용 ---- subject=CN = a7cf2750c76a issuer=CN = Elasticsearch security auto-configuration HTTP CA --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 6541 bytes and written 281 bytes Verification: OK --- New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 4096 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 362F6B5369DB4D85D09490F9D30E7DF66367B120D1EDEF9DF0013644F1D0FCA8 Session-ID-ctx: Master-Key: 5C3994FFD364BFF28A8990102CA6EDCC99D9F8AEBD0B9E2905DA3F9B6BE1CF3F8787648205B6F46AD3D1D8CA7A7EEA02 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 86400 (seconds) TLS session ticket: ----- session ticket 내용 ----- Start Time: 1744073205 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: yes

추가됐습니다! 도와주셔서 진심으로 감사드립니다!좋은 하루 되세요!

git flow 이미지에서1. release 브랜치는 점으로만 존재하는데 운영 배포될 때마다 release 브랜치도 계속 범위를 늘려가며 존재하는게 아닐까요??release 브랜치 생성시 버전을 붙여서 각각의 다른 브랜치로 그때만 사용되는걸까요??2. 실습화면에서 만약 협업하는 사람이 3명일 경우, 3명이 모두 각각 코멘트를 작성하고, 3명 모두 각각 merge pull request 버튼을 다 눌러야 pull request가 되는걸까요??  3. 깃헙에서 conflict가 발생할 경우도 협업하는 사람이 여러명일 경우 어떻게 되는지 궁금합니다. pull request 요청시에 merge pull request 버튼이 비활성화 된걸 보고 작업자가 요청한 pull request를 취소?하고 로컬에서 conflict를 해결하고 다시 새로운 pull request를 요청하는 걸까요??

강의 화면에 나오는 github의 Settings의 항목들과 제 github의 항목이 차이나는데.. 왜 이런걸까요? 

두 차례 요청 드렸는데.. 아직 자료를 받지 못했네요... 아래 메일 주고 남겨 놓습니다. 강의 자료 부탁드립니다. seba2064@gmail.com

파일을 불러오는 중 오류가 발생했습니다.파일을 찾지 못했습니다. 파일이 존재하지 않거나 읽기 권한이 없습니다. 라고 뜨는데, 파일이 없는 거 아닌가요? 권한은 전부 부여되어있는 상태입니다.그리고 보니까 이미지 상으로는 diagrams.net 인데 지금은 draw.io 로 바뀌어있더라고요. 이거 관련해서 관리자분이 설정을 따로 해주셔야 하는 거 아닌지... 조심스럽게 확인 요청 드립니다.

main브랜치에서 커밋을 1, 2, 3을 생성했는데, 커밋 2버전에서 새로운 브랜치를 생성해서 작업을 진행하려면 어떻게 해야 하나요??checkout으로 HEAD가 해당 커밋(2번 커밋)을 가리키게 하고 거기서 브랜치를 생성하여 작업진행하는 걸까요?아니면 revert?로 3에서 2로 변경된 내용을 새로 커밋하여 최신커밋(main commit 4)이 2의 내용을 가리키게 하여 거기서 브랜치를 새로 만드는 걸까요??git commit - m "main commit 1" git commit - m "main commit 2" git commit - m "main commit 3" git checkout 1234567 # <- main commit 2 이동 git branch test git checkout test #=========================================== git commit - m "main commit 1" git commit - m "main commit 2" git commit - m "main commit 3" git revert 1234567 # <- main commit 2 내용으로 새로운 commit 생성 git branch test git checkout test )) revert의 내용을 잘 이해한건 맞겠죠??;;;;;

저장소간의 차이점을 구체적으로 볼 때 git diff를 사용한다는 점은 이해했습니다.언제 또 사용하게 되나요?

강의 내용 똑같이 따라해봐도 redis, node 버전 관련 문제로 실행할 수 없었습니다..!저는 아래 코드로 테스트 성공했으니 참고 부탁드려요! Dockerfile >>>> node version 16 FROM node:16 WORKDIR /usr/src/app COPY ./ ./ RUN npm install CMD [ "node", "server.js" ] package.json>>> redis version 4.7.0{ "name": "nodejs-docker-compose-app", "version": "1.0.0", "main": "server.js", "scripts": { "start": "node server.js", "test": "echo \"Error: no test specified\" && exit 1" }, "dependencies": { "express": "4.17.1", "redis": "4.7.0" }, "author": "", "license": "ISC", "description": "" }  docker-compose.ymlversion: "3" services: redis-server: image: redis container_name: redis-server restart: unless-stopped expose: - 6379 node-app: depends_on: - redis-server build: context: . dockerfile: Dockerfile container_name: node-app restart: on-failure ports: - "8081:8080"  server.jsconst express = require("express"); const redis = require("redis"); const app = express(); // Redis 클라이언트 생성 const client = redis.createClient({ socket: { host: "redis-server", port: 6379 } }); async function connectToRedis() { let connected = false; while (!connected) { try { await client.connect(); console.log('Connected to Redis'); connected = true; } catch (error) { console.error('Error connecting to Redis:', error); console.log('Retrying in 2 seconds...'); await new Promise(resolve => setTimeout(resolve, 2000)); } } } // Express 엔드포인트 설정 app.get('/', async (req, res) => { try { let number = await client.get('number'); if (number === null) { number = 0; } console.log('Number: ' + number); res.send("숫자가 1씩 올라갑니다. 숫자: " + number); await client.set("number", parseInt(number) + 1); } catch (error) { console.error('Error:', error); res.status(500).send('Redis 연결 오류'); } }); // 서버 시작 전에 Redis 연결 app.listen(8080, async () => { await connectToRedis(); // 서버 시작 시 Redis 연결 시도 console.log('Server is running on port 8080'); });  모두 저장 후 터미널에서docker compose down docker compose up --build    

트레비스가 유료화되어 챕터8에서 aws설정하는 부분까지만하고 멈춘 상태인데요 ㅎㅎ이후로는 트레비스를 통해 aws 반영하는 부분인 것 같더라고요. 혹시 남은 트레비스 부분을 제외하고 9장으로 넘어가도 괜찮을지 궁금합니다 ㅎㅎ

좋은 강의 만들어주셔서 감사합니다!덕분에 막연했던 배포에 대해 조금씩 알아가고 있습니다!혹시 강의 들으면서 정리한 내용을 블로그에 포스팅해도 괜찮을까요?

안녕하세요. 수업 잘 듣고 있습니다! 한가지 질문을 하려고 하는데요이미 올라간 소스코드가 있는 github 레파지토리 자체를 삭제한다면 아무도 그 소스코드에는 접근을 못하는 건가요?

강사님 테마가 너무 좋은거 같아서 그런데.. 찾아봐도 똑같은게 없네요 ㅠㅠ 

rebase conflict 질문드립니다.강의에서는 rebase시에 test branch에서 main branch로 범위가 수정되면서 main branch의 최신 commit을 가리키고 있다가 베이스로부터 기존 test branch에 있다가 떨어져 나온 커밋들의 변경분에 대해 하나씩 tracked area와 staging area에 반영이 되고 여기서 같은 위치에 수정이 일어났으니 conflict가 난다고 말씀주셨는데 이게 기존 3-way-merge 와는 좀 다른 거 같아서요. 기존 3-way-merge에서는 base 커밋에 따른 diff를 찾다 보니 두 브랜치의 같은 위치에 동시에 수정이 일어났을 경우에는 git이 어떤 걸 최종적으로 반영해야 할 지 몰라 conflict가 난다고 알고 있는데 여기서는 base 커밋에서의 diff를 확인하는게 아니기 때문에 노란색이 초록색으로 수정되었다고 생각해야 하는 거 아닌가요 ? 예를 들어 main branch가 하나만 있고 여기서 yellow를 green으로 수정해서 커밋하는게 가능하듯이 설명에서 보면 head가 가리키는 게 최신 커밋이고 여기서 변동분을 반영하는 거니까 동시에 같은 부분이 변경이 되어서 뭘 반영해야 할지 모르는 것과는 좀 다른 거 같아서요.감사합니다.

브랜치 상황이 원격에 dev, feat/member 가 있고 로컬에도 dev, feat/member가 있다고 하겠습니다.이때 제가 로컬 feat/member 브랜치에서 작업 중인데 원격 dev 브랜치에 있는 작업 내용을 제가 작업 중인 로컬 feat/member 브랜치로 가져오려면 어떻게 해야 하는지 궁금합니다.

Push 실행 시 자동으로 트래킹 브랜치가 생성되거나 덮어쓴다고 하셨는데, 여기서 생성되거나 덮어쓰는게 fetch하는거랑 똑같다고 봐도 되나요? 아니면 조금 다른가요?

섹션 4 충돌해결하기에서 main 브랜치에서 Tigers의 manager를 Kenneth로 변경Leopards의 coach를 Nicholas로 변경Panthers의 coach를 Shirley로 변경커밋 메시지: Edit Tigers, Leopards, Panthers을 했어야했는데 main 브랜치에서 전부 manager의 이름으로 변경해버려서 이후 conflict-2에서 충돌이 일어나지 않는 상황이 발생했습니다..이 커밋 내용만 수정하는 방법이 있을 까요?

 taehyeonkoo@TaeHyeonui-MacBookPro ~ % cd myProjectcd: no such file or directory: myProjecttaehyeonkoo@TaeHyeonui-MacBookPro ~ % cd ~/데스크탑cd: no such file or directory: /Users/taehyeonkoo/데스크탑taehyeonkoo@TaeHyeonui-MacBookPro ~ % cd ~/Desktoptaehyeonkoo@TaeHyeonui-MacBookPro Desktop % cd myprojectcd: no such file or directory: myprojecttaehyeonkoo@TaeHyeonui-MacBookPro Desktop % cd projectstaehyeonkoo@TaeHyeonui-MacBookPro projects % cd myProjecttaehyeonkoo@TaeHyeonui-MacBookPro myProject % 처음 명령어 cd myProject 를 치면 바로 안나오는데 정상인가요?

안녕하세요강의 정말 잘봤습니다!!그 동안 필요할 때마다 서칭해서 깃과 깃허브에 대해 단편적으로만 알고 있었는데 이 강의를 통해 제대로 쉽고 빠르게 배울 수 있었습니다! 정말 감사합니다~강의 자료를 통해 다시 한 번 공부해보고 싶은데 강의 자료 받을 수 있을까요??ehdgus6503@naver.com 입니다!

working directory에 circle과 rectange 파일이 있다고 가정하고, 이 파일들이 staging area를 걸쳐 repository에 commit이 완료된 상태라고 가정하겠습니다. 이 과정에서 circle 파일의 내용을 수정한다면, 이 circle 파일은 tracked 상태로 남아있는 것인지 아니면 내용이 수정되었기 때문에 untracked 상태로 변경되는 것인지 궁금합니다. 또한, 만약 위 상황에서 circle 파일의 내용이 변경되었더라도 동일한 circle이라는 파일명을 가지고 있기 때문에 tracked 상태가 유지된다면, circle 파일을 복사한 새로운 이름을 가진 파일 (recircle)이라는 파일의 상태는 tracked인지 untracked인지 궁금합니다.