클라우드 서비스를 이용하게 되면 기본적으로 시간은 UTC +00:00 기준으로 설정된다. 한국시간 기준으로 타임존을 설정하려면 timedatectl 명령어를 사용하면 된다.
우선 timedatectl만 입력하면 상태값들을 확인할 수 있다.
그리고, 아래와 같이 입력하면 Asia/Seoul 기준의 타임존 설정이 끝난다.
sudo timedatectl set-timezone Asia/Seoul
양말 바닥도 뭐 엄청 성하진 않지만, 그래도 조금이라도 더 신을 수 있으면 신어보자공! 엄마 아빠의 바느질을 어깨너머로 배운 서당개 40년 실력은 역시 그냥 서당개구나ㅋㅋ오늘은 10일차 챌린지!
화장실에서 대사를 치른 후에 휴지 조금만 사용하기!
사실 계속 줄여왔다. 6장을 사용하다가 너무 많이 쓰는 거 아닌가 싶은 생각에 5장, 그리고 4장까지 줄였는데, 3장도 해볼만 하겠다 싶어서 3장에 도전했다. 그리고 성공!!
반 접고, 1/3씩 접은 후, 1차.
다시 반 접고, 2차.
다시 반 접고, 3차!
오늘은 9일차 챌린지!
사용하지 않는 스위치는 꺼놓기! 8일차!
떡볶이 비닐에 안 담고, 김밥 호일에 안 싸오고, 그릇에 담아오기! 7일차!
‘차별이 아닌 빛나는 별이 될 수 있도록!’ 아동권리증진 캠페인 영상을 보고ㅡ 함께 참여해요!
아동권리캠페인 영상 -> https://youtu.be/jCnph5j9OXc
11월 19일 세계아동학대예방의 날을 기억하며,
대한민국에 거주하는 모든 아동이 기본권을 보장받는 사회가 될 수 있도록 아동권리증진 캠페인 영상을 만들었습니다.
모든 아동의 기본권이 보장될 수 있도록 우리모두 함께해요!
[함께 참여할 수 있는 방법]
방법1. 영상 좋아요 누르기!
방법2. 개인SNS에 아래 해시테그를 복사&붙여넣기 후 영상 공유하기!
방법3. 11월 19일 세계아동학대예방의날을 알리기!
#11월19일 #세계아동학대예방의날 #차별아닌빛나는별 #우리모두함께해요 #아동권리증진캠페인 #이주아동 #UN아동권리협약 #재단법인바보의나눔 #사단법인희망씨
휴지심을 모아서 케이블 정리함을 만들었다! 6일차!
기후위기가 모기와 관련되어 있다는 내용의 영상이 있어서 소개하려 한다.
https://www.facebook.com/Hey.News.JTBC/videos/857593698280211
올 가을에 우리집은 하루에 30마리까지 모기를 잡은 적이 있다.
영상을 보고 든 생각
기후위기와 모기 관련 영상 요약
내가 생각하는 결론
지금 지구 생태계는 스파게티코드 같은 상태다. 전 지구적으로 생태적 리팩터링이 필요한 시점이다.
참고)
스파게티코드: 프로그램 소스 코드가 마치 스파게티처럼 복잡하게 얽힌 모습에 비유한 것
리팩터링: 프로그램의 소스코드를 개선하는 작업
집에 있는 장바구니와 보온가방으로 장 보기!! 비닐 한 장 덜 쓰기! 근데 엄청 많이 장바구니 써야 비닐보다 효율이 좋단다. 그래서 매일같이 엄청 쓰는 중!! 5일차!
처음엔 아래와 같은 방식으로 작성했는데, 이렇게 하는 경우 proxy_pass를 통해 https의 해당 도메인으로 정확히 연결되지 않는 현상을 발견하였다. 현재 사용할 서버는 PHP 아닌데, 왜 PHP가 뜨는 거지? 오잉? 싶었는데, 다른 서비스 용으로 PHP가 돌아가고 있었다. 즉, 엉뚱한 도메인으로 연결되고 응답으로 404 Not Found를 돌려받고 있었다. Oh my gosh! 왜 이런 현상이 생기는 것이지? 이건 분명 도메인으로 넘어가지 않고 IP로 넘어가서 발생한 현상일 듯한데 싶었다. 그렇다면 어떻게 이걸 명확하게 도메인으로 넘겨줄 수 있을지 고민이 되었다.
http {
...
upstream servers {
server first.myserver.com:443;
server second.myserver.com:443;
}
server {
listen 443 ssl;
location / {
proxy_pass https://servers;
}
...
}
}
그리고서 구글링을 하다가 힌트(https://stackoverflow.com/questions/29071168/nginx-upstream-with-http-https/65767299)를 발견한 후 아래와 같이 수정하였다.
http {
...
upstream servers {
server 127.0.0.1:8081;
server 127.0.0.1:8082;
}
server {
listen 443 ssl;
location / {
proxy_pass http://servers;
}
...
}
server {
listen 8081;
location / {
proxy_pass https://first.myserver.com;
}
}
server {
listen 8082;
location / {
proxy_pass https://second.myserver.com;
}
}
}
드디어 로드 밸런싱이 원하는대로 작동하기 시작했다.
정리해보면, nginx의 소스코드를 까보지 않아서 왜 이런 현상이 발생하는지는 정확히 모르겠지만, 추론컨대 전자의 경우 domain으로 작성하지만 IP와 포트로만 처리하는 것으로 보인다. 왜냐하면 동일 머신에 필자가 운용중인 다른 서비스로 접근하는 것을 확인했으니 말이다. 후자의 경우는 각각의 proxy 서버가 명확하게 목적지를 가리키고 있으므로 문제가 발생하지 않았던 것으로 보인다.
단일 서비스만 운용하는 경우에는 별 문제가 되지 않을 수 있겠지만, https로 이용하는 서비스가 여러 개 있다면 필자와 같이 문제가 발생할 수 있다.