기억 파편

1. 인증서를 발급받고 FMN에서 통합인증서와 KEY 파일을 다운로드 받는다.
2. 리눅스 서버로 파일을 업로드한다.
3. nginx의 conf 파일에 해당 인증서 파일 경로를 변경한다. 혹은 인증서파일 자체를 교체한다.
   1. 경로 변경 시, nginx -t 명령어로 문법에 오류가 있는지 확인한다.
   2. passphrase 없는 인증서를 만들어서 적용; 이 때 서버 권한 확인
   3. sudo openssl rsa -in /nginx/conf/key.pem -out /nginx/conf/key_nopass.pem -passin pass:'passphrase'
4. nginx -s reload 명령어로 변경한 내용을 적용한다.
5. 브라우저에서 인증서 정보가 변경되었는지 (발급일, 만료일) 확인한다.

reload 하기 전 까지는 파일 이동/변경해도 잡히지 않음

클라우드는 하드웨어가 어디에 위치해있고 어떻게 운영하는지에 따라 구분됨

• public
  • 일반 사용자들; 인터넷만 있으면 바로 사용 가능
• private
  • 보안; 거버넌스
  • 하나의 기업/조직의 선택된 사용자만 독점적으로 사용
  • 초기 하드웨어 구매 필요
  • private cloud 도입한 조직이 리소스 및 보안을 완전히 제어; 하드웨어 유지 관리 및 업데이트
  • 비용이 들긴 함
• hybrid
  • private + public
  • 상황에 따라 유연하게
  • 네트워크 중요
• multi 
  • 두 개 이상의 외부 클라우드를 활용
  • aws + azure 
  • 다른 리전보다 다른 클라우드 서비스 프로바이더(csp)를 선택, 특화된 서비스를 위해 혼용하기도

클라우드는 인프라 리소스를 제공받는 범위에 따라 아래처럼 구분됨

• IAAS
  • 인프라, 서버, 저장소, 네트워킹 제공
• PAAS
  • os, middle ware 까지 제공; 디비(RDS)
• SAAS
  • 전체 서비스/상품 제공; 두레이
• DAAS
  • desktop as a service
  • 시간/장소/기기에 상관없이 언제 어디서나 개인의 업무환경에 접속할 수 있는 환경을 제공

책임공유모델

• 서비스 제공자(CSP)와 사용자가 함께 보안과 운영에 있어 각자 책임을 짐

apache 설정 중 virtual-host의 프록시 부분을 수정하였는데 304 NOT_MODIFIED 라는 문구와 함께 화면이 나오지 않았다.

나의 경우는 스웨거 페이지를 열려고 프록시에 아래처럼 /swagger-ui 를 추가한건데 스웨거 페이지가 열리지 않는 것이 아닌가..

  ...  
    ProxyPass /api http://localhost:6003/api
    ProxyPassReverse /api http://localhost:6003/api
    ProxyPass /swagger-ui http://localhost:6003/swagger-ui
    ProxyPassReverse /swagger-ui http://localhost:6003/swagger-ui
...

알고보니 스웨거 resource(이미지 등)을 불러오기 위해서 다른 url 호출이 있는데(/v3/api-docs/ 등) 이를 아파치 프록시에 설정하지 않아서 생기는 오류였다.

해결: 모든 resource path를 알기 어려워서 /로 bypass하도록 열어두었다(개발용 내부망이라 보안에 위배되지는 않는다. 만약 디테일하게 걸어야하면 관련 path 분석하여 넣어야 함).

이미 git에 연결된 repository의 git의 주소 변경

> git remote -v
origin #old git url#

> git remote add origin #new git url#
error: origin 리모트가 이미 있습니다.

> git remote set-url origin #new git url#

> git remote -v
origin #new git url#

이렇게만 하면 빈 repository에 아무것도 안 뜨는데

브랜치에 커밋된 상태 그대로 옮기려면 아래 명령어를 입력하면 된다.

## 모든 브랜치
git push -u --all


# 각 브랜치
git push -u origin develop

docker vs kubernetes

docker 도커

• 도커는 환경이 다른 곳에도 같은 환경을 유지할 수 있도록 하는 기술(개발환경과 배포 환경을 동일하게 관리할 수 있음)
• 1 docker - n isolated containers; 하나의 같은 서버에서 각기 다른 환경의 컨테이너를 설정 가능
• 원하는 환경을 파일에 저장하면 도커는 어떤 머신에든 해당 환경을 simulate 해줌
• 이런 환경들은 각기 독립적으로 존재, 어떠한 환경이든 모듈식으로 관리 가능
• dockerfile(컨테이너를 어떻게 만들어야 하는지 설명서) -> image 생성(세팅 포함; 스냅샷; 변경 불가 불변) -> 컨테이너로 배포(고립된 환경 안에서 실행)
• 로컬 pc에서 이미지를 PUSH -> container registry에 저장되고 -> 이걸 서버에서 PULL받아서 실행(서버에도 도커와 같이 container engine 설치되어 있어야)

kubernetes 쿠버네티스

• 여러 컨테이너가 있을 때 편하게 관리하게 할 수 있는 도구
• 어떻게 운영할지 자원으로 정의
• 자동 확장/축소/zero time patch/모니터링/로드밸런싱 등 제공

container vs vm

https://learning.postman.com/docs/designing-and-developing-your-api/mocking-data/setting-up-mock/

화면을 개발할 때 백엔드 api를 기다리며 개발을 홀딩하다가 api가 배포되면 그제야 화면에 연동하는 작업을 하게 되는 경우가 많다. 물론 이 과정도(실제 api와 연동) 필요한 과정이지만 기다리는 시간이 낭비된다. 이때 api spec만 알면 간편하게 목 서버를 만들어서 개발하다가 api가 배포되면 url만 교체해서 확인하면 시간을 절약할 수 있다.

목 서버를 만드는 방법은 위 링크처럼 여러 가지가 있지만 나는 collections에 샘플 req/res를 만들어놓고 mock server로 전환하는 편이다.

이때 아래와 같이 샘플 response를 미리 저장해야 한다. 각 api에서 add example을 통해 등록한다.

그리고 콜랙션을 목서버로 만든다. info를 누르면 목 서버를 만들 수 있는 창이 뜬다.

이때 url을 환경변수로 설정해두면 목서버를 만들 때 해당 목 서버가 자동으로 환경변수로 등록되어 url 전환이 쉬워진다. 또한 나중에 api가 다른 서버에 배포되었을 때 환경변수로 url을 등록만 해놓는다면 바로 전환해서 요청이 가능하므로 매우 유용하다.

환경변수는 왼쪽 environments 탭에서 설정 가능하다.

추가적으로 만든 목 서버/collection에 대한 api doc을 발행할 수도 있다.

documentation -> publish 하면 발행이 되고 최종 발행이 되면 url 생성된다. 이 url로 다른 사람도 나의 목 서버의 스펙을 확인, api를 요청할 수 있다(private 한 발행도 가능하다).

1. restart 

(13)Permission denied: make_sock: could not bind to address 0.0.0.0:80

아파치를 재시작할 때 위와 같이 권한 에러가 나는 경우가 있다.

아파치를 80 포트로 띄우는데, 1024 이하의 well-known 포트는 root 만 접근이 가능한데, root 계정이 아닌 계정으로 띄우니 에러가 난 것이다. 실제로 파일의 소유권을 보면 root가 아니라 www 계정이다.

[irteamsu@wa901 apache]$ cd bin
[irteamsu@wa901 bin]$ ll
total 2796
-rwxr-xr-x 1 www www  144096 Jun 16 10:52 ab
-rwxr-xr-x 1 www www    3455 Jun 16 10:50 apachectl
-rwxr-xr-x 1 www www    7017 Jun 16 10:52 apr-1-config
-rwxr-xr-x 1 www www    6611 Jun 16 10:52 apu-1-config
-rwxr-xr-x 1 www www   22662 Jun 16 10:50 apxs
-rwxr-xr-x 1 www www   13048 Jun 16 10:52 checkgid
-rwxr-xr-x 1 www www    8925 Jun 16 10:50 dbmmanage
-rw-rw-r-- 1 www www     987 Jun 16 10:50 envvars
-rw-rw-r-- 1 www www     987 Jun 16 10:50 envvars-std
-rwxr-xr-x 1 www www   56480 Jun 16 10:52 htcacheclean
-rwxr-xr-x 1 www www   34160 Jun 16 10:52 htdbm
-rwxr-xr-x 1 www www   25280 Jun 16 10:52 htdigest
-rwxr-xr-x 1 www www   37000 Jun 16 10:52 htpasswd
-rwxr-xr-x 1 www www 2384976 Jun 16 10:52 httpd
-rwxr-xr-x 1 www www   22816 Jun 16 10:52 httxt2dbm
-rwxr-xr-x 1 www www   25200 Jun 16 10:52 logresolve
-rwxr-xr-x 1 www www   27360 Jun 16 10:52 rotatelogs

쉘의 소유주를 변경하고 root가 아닌 계정에서도 실행할 수 있게 권한도 변경한다.  

's' = The directory's setgid bit is set, and the execute bit is set.

[irteamsu@wa901 bin]$ sudo chown root:www httpd
[irteamsu@wa901 bin]$ sudo chmod +s httpd
[irteamsu@wa901 bin]$ sudo chown root:www apachectl 
[irteamsu@wa901 bin]$ chmod +s apachectl

-rwxr-xr-x 1 www  www  144096 Jun 16 10:52 ab
-rwsr-sr-x 1 root www    3455 Jun 16 10:50 apachectl
-rwxr-xr-x 1 www  www    7017 Jun 16 10:52 apr-1-config
-rwxr-xr-x 1 www  www    6611 Jun 16 10:52 apu-1-config
-rwxr-xr-x 1 www  www   22662 Jun 16 10:50 apxs
-rwxr-xr-x 1 www  www   13048 Jun 16 10:52 checkgid
-rwxr-xr-x 1 www  www    8925 Jun 16 10:50 dbmmanage
-rw-rw-r-- 1 www  www     987 Jun 16 10:50 envvars
-rw-rw-r-- 1 www  www     987 Jun 16 10:50 envvars-std
-rwxr-xr-x 1 www  www   56480 Jun 16 10:52 htcacheclean
-rwxr-xr-x 1 www  www   34160 Jun 16 10:52 htdbm
-rwxr-xr-x 1 www  www   25280 Jun 16 10:52 htdigest
-rwxr-xr-x 1 www  www   37000 Jun 16 10:52 htpasswd
-rwsr-sr-x 1 root www 2384976 Jun 16 10:52 httpd
-rwxr-xr-x 1 www  www   22816 Jun 16 10:52 httxt2dbm
-rwxr-xr-x 1 www  www   25200 Jun 16 10:52 logresolve
-rwxr-xr-x 1 www  www   27360 Jun 16 10:52 rotatelogs

그럼 권한 문제는 해결된다.

2. stop

/usr/local/apache/bin]# apachectl stop
...
httpd (no pid file) not running

아파치를 정지하는데 위와 같은 메시지가 뜨면서 정지가 안 되는 현상이 있다. 아마 1번이 진행되지 않은 상태에서 아파치가 실행되었는데 중간에 권한이 바뀌어서 문제가 되는 것으로 보인다. 실제로 ps로 서비스를 확인해보면 정지가 안 되어 있는 걸 확인할 수 있다.

이 현상은 정지할 때 ../logs 폴더에 httpd.pid 파일을 가지고 정지를 시키는데 어떤 이유로 아파치 실행 시 해당 파일이 없을 경우 나는 에러였다. 

/usr/local/apache/logs]# ll

drwxr-xr-x 15 www www 175  6?? 16 10:52 ..
-rw-r-----  1 www www   0  6?? 16 10:56 modsec_debug_log

위 경로로 가서 httpd.pid 파일을 만들고 pid를 넣어준다.

[wa902 logs]$ ps -ef | grep -E "httpd[[:space:]]-k" | grep -v "grep" 
root     14827     1  0 Jun16 ?        00:00:03 /home/www/apps/httpd-2.2.21/bin/httpd -k start
www      14843 14827  0 Jun16 ?        00:00:00 /home/www/apps/httpd-2.2.21/bin/httpd -k start
www      14846 14827  0 Jun16 ?        00:00:00 /home/www/apps/httpd-2.2.21/bin/httpd -k start
www      14848 14827  0 Jun16 ?        00:00:00 /home/www/apps/httpd-2.2.21/bin/httpd -k start
www      14850 14827  0 Jun16 ?        00:00:00 /home/www/apps/httpd-2.2.21/bin/httpd -k start
www      14852 14827  0 Jun16 ?        00:00:00 /home/www/apps/httpd-2.2.21/bin/httpd -k start
www      14853 14827  0 Jun16 ?        00:00:00 /home/www/apps/httpd-2.2.21/bin/httpd -k start
www      14854 14827  0 Jun16 ?        00:00:00 /home/www/apps/httpd-2.2.21/bin/httpd -k start
www      14855 14827  0 Jun16 ?        00:00:00 /home/www/apps/httpd-2.2.21/bin/httpd -k start
www      14856 14827  0 Jun16 ?        00:00:00 /home/www/apps/httpd-2.2.21/bin/httpd -k start
www      14857 14827  0 Jun16 ?        00:00:00 /home/www/apps/httpd-2.2.21/bin/httpd -k start

[wa902 /usr/local/apache/logs]# cat httpd.pid 
14827

그리고 다시 apachectl stop을 하면 잘 되는 것을 확인할 수 있다.

환경: docker, mysql8.0.29

r2dbc:mysql://localhost:3306/webflux

스프링 설정 상, DB url이 위와 같더라도 스프링에서 r2dbc를 사용할 뿐, 인텔리제이 등 다른 DB client에서는 아래와 같이 jdbc로 사용하면 된다.

연결 후 mysql 명령어를 실행하면 다음과 같은 로그가 지나간다.

mysql        | mbind: Operation not permitted

docker-compose.yml에 위와 같이 security_opt 부분을 추가하고 docker-compose up 으로 다시 구동시키면 에러가 안 난다.

도커 쪽 문서를 보니 seccomp profile이 없을 때 나는 에러인 듯 하다.

환경: docker, mongo 5.0.9

Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a YAML file to configure your application’s services. Then, with a single command, you create and start all the services from your configuration.

docker-compose.yml 에 아래와 같이 설정하여 docker-compose up 명령어로 실행 시..

db client tool에서는 아래와 같이 접속을 시도해야한다.

mongodb://nhn:nhn@localhost:3307

유저를 주지 않으면 authentication 에러가 나고, 잘못된 포트를 주면 connection 에러가 난다..

 An error occurred while loading instance info: command hostInfo requires authentication

connect ECONNREFUSED 127.0.0.1:27017

여기서 헷갈렸던 부분이 포트인데, yml에는 3307:27017 이렇게 적혀있어서 왜 저렇게 쓰는지 의문이었는데,

앞 포트(3307)은 외부 노출 포트고 뒤 포트(27017)는 컨테이너 포트인 것 같다.

Expose ports.
Either specify both ports (HOST:CONTAINER), or just the container port (a random host port will be chosen).

어쨋건 mongoDB의 내용을 더 편하게 볼 수 있는 클라이언트(mongo compass)까지 확인 완료.

위 내용은 intellij에서도 확인가능하며 콘솔 명령어로도 조회할 수 있어 더 편리한 것 같다.

mongo db 간단 명령어

# mongo 접속
mongo -u nhn -p nhn

# 현재 로그인 정보
db.runCommand({connectionStatus: 1})

# db list
show dbs
# db change
use webflux
# see table
show tables
= show collections

# table을 collection이라고 부름에 주의
# chat table 조회
db.chats.find()

아래 명령어가 정리된 문서가 있는데, collection에 실제 콜랙션 이름을 넣어야 한다. collection은 일반 dbms의 테이블과 같은 용도이다.

https://www.mongodb.com/docs/manual/reference/mongo-shell/

그리고 보다보니 find와 aggregate가 비슷해 보였는데(일반 select절의 where문과 같이 필터링하는 역할) 깊이 보면 차이가 있는 듯하다.

https://secretartbook.tistory.com/21

아직 실제로 막 써보지 않아서 와닿지는 않는다.

https://blog.silnex.kr/dockerdocker-compose-%EC%A0%95%EB%A6%AC/

linux의 .bash_profile과 같은 파일은 한 번 만들고 source 명령어를 통해 활성화하면 다음부터는 별다른 실행 없이 바로 적용되는 것을 알 수 있다. 허나 mac 같은 경우에는 그렇지가 않아서 매우 귀찮았는데, 이는 최초에 초기화 시 불러오는 파일명이 달랐기 때문이다.

아마 최초에 zsh관련 라이브러리를 설치했기 때문이 아닌가 싶긴한데, 내 컴퓨터에서는 아래의 이름을 된 파일이 최초에 읽어진다.

.zshrc

따라서 저 파일을 생성하고 그 안에 작성하면 무엇이든 두 번씩 하지 않아도 된다.

나는 이미 .bash_profile에 적어뒀던지라 그냥 그 파일을 읽어오게 했다.

if [ -f ~/.bash_profile ]; then
  . ~/.bash_profile
fi