기억 파편

아키텍트의 역할 / 능력이란?

1. 아키텍처 결정

• 기술을 선택해주진 않지만 선택하는데 가이드를 준다(비동기를 써, 그게 카프카인지 래빗인지는 니네가 결정해)
• 하지만 필요 시 기술 지정 할수도..

2. 지속적으로 아키텍처 분석

• 최근 동향 확인, 비즈니스의 흐름에 따른 개선 제안

3. 최신 트랜드 유지

• 롱텀으로 생각, 미래를 대비

4. 결정 사항 준수 확인

• 설계 원칙을 따르는지 지속적으로 검증
• 기대한대로 작동하는지 확인

5. 다양한 경험 필요

• 다양한 기술 프래임워크 플랫폼 환경에 대한 경험
• 다양한 기술에 친숙해야 함
• 기술의 깊이보다는 폭에 집중

6. 업계/도매인의 지식 필요

• 기술 뿐 아니라 비즈니스적 요소도 이해해야 함
• 비즈니스 요구를 만족하는 설계 필요
• 고객/이해당사자 등과 소통 필요

7. 대인 관계 / communication

• 어떠한 일이건 사람의 문제
• 리더쉽, 팀웍, 동기유발

8. 회사 내부 상황 파악 / 정치

• 아키텍트의 결정은 도전을 받음
• 결정에 따라 비용, 시간, 인력 등에 영향
• 협상능력 필요

지금은 개발자이지만, 궁극적으로는 기술 pm이나 팀/그룹 리더, 나아가서는 아키텍트가 되고 싶은 마음에 찾아본 내용
개인적인 취향도 깊이보다 폭, 기술보다는 사람이라 생각하여 나와 맞을 수 있을거라 생각하면서도.. 설득, 협상능력 이런건 자신이 없기에 아직은 막연하다. 뭐 우선 관련 기회가 주어져야겠지..

The Fundamentals of Software Architecture

CQRS는 Command and Query Responsibility Segregation(명령과 조회의 책임 분리)의 약자이다. 

**명령(Command)**와 **조회(Query)**의 책임을 분리하여 시스템의 확장성과 유지보수성을 높이는 데 목적이 있으며..

쉽게 말해서 data에 대한 read와 write는 분리되어 개발되어야 한다는 것이다.

eventually consistent!

1. Before

설명을 하기 전에 그림을 먼저보자. 먼저 아래는 일반적인 우리의 서버 구조이다.

api 만 다를 뿐 결국 같은 서비스 안에서 같은 디비를 바라보고 있다. 백 만 건의 조회가 생겨 디비 행이 걸리면 업데이트에도 지연이 있을 수 있고 반대로 몇 천 건을 수정할 경우 디비 락이 걸려 조회가 안될 수도 있다. 이를 개발하는 소스 안에서도 게으른 개발자는 등록과 조회가 같은 dto를 사용할 수도 있고 한 dto 안에서 등록용 함수, 조회용 함수 등이 덕지덕지 섞여 어느샌가 리팩토링 조차 힘든 상황이 올 수도 있다.

2. Initial CQRS

그렇다면 CQRS는 어떤 개념인가. 아래 그림을 보자.

CQRS를 처음 제시한 사람은 CQRS에 대해 아주 단순하게 말했다.

It has one simple assumption: instead of having one big model for reads and writes, you should have two separate models. One for writes and one for reads.

단순하게 말하면 등록/조회 같은 dto 쓰지마라..ㅋ (사실 더 나아가선 application도 분리해야한다; 녹색이 어플리케이션, 노란색이 dto라고 보면 된다)

그리고 두 가지 개념을 들고온다: query와 command

Query should not modify anything, just return the data.
Command is the opposite one: it should make changes in the system, but not return any data.

나는 query는 조회용, command는 업데이트(수정,등록 등)용이라고 이해했다(다른 원문에서는 read와 update 라고 분리하기도하는데 공통된 의미라고 생각한다).

위 그림에서도 내부적인(service; dto, 함수 등) 분리는 된 듯 한데, DB의 분리는 아직이다. 사실 이 정도만 분리해도 괜찮다(현실적이다)는 평도 있다.

3. Ultimate CQRS

하지만 모든 원론이 그러하듯 궁극적인  CQRS는 한 단계 더 진화한다. 필자도 경험해봤지만 결국 대용량 서비스는 조회의 싸움이다.

특히 MSA 구조에서 데이터 조회란, 수 많은 테이블의 join의 결과체이며 이로인해 DB cpu가 100을 찍는 경우도 허다하다.

궁극적인 CQRS는 아래와 같이 제안한다.

차이점은 read, write의 완전한 분리 그리고 event sourcing

여기서 핵심 내용은 write 와 read 할 때 사용되는 db(물리적인 db, in-memory db 등 데이터를 저장하는 모든 것을 일컬음)는 communicate이 불가하고 오로지 event를 통해서만 communicate 할 수 있다는 점이다.

위 플로우를 write -> event storage(업데이트 로그) -> events -> event handler -> write 라고 설명하는 사람도 있는데, 이 때 event storage가 전체 플로우 중 transactional 이 가능한 유일한 아이라고 설명하는 사람도 있다(write할 때도 event storage에 event생성만 하고 끝이니 딱히 transacitonal할 필요 없음). 적당히 이해하고 보면 될 듯 하다.

정리하면 아래와 같다.

위 처럼 분리되었을 경우의 아래와 같은 장점을 얻을 수 있게 된다.

• 각각의 상황에 맞게 optimize가 가능(ex. read - view with cache)
• read와 write가 서로 독립적(즉 서로 영향을 미치지 않는다; 조회하다 부하가 걸려 업데이트가 안 될 일이 없다).
• 독립적인 scaling(조회가 많으면 조회 쪽 성능에 대한 개선만 하면 됨/ 관련 인프라의 scale out)이 가능

이를 공부하면서 의문이 생기는 것은 배달 주문 메뉴 수정/실시간 잔액 조회와 같이 실시간 반영이 필요할 때 event driven의 경우 아무래도 write -> read로 가는 약간의 지연이 있을 것 같은데 이는 어떻게 해결할 수 있는지, 무시할만한 수준인건지 궁금하다..(왠지 진짜 실시간은 write 테이블을 보고 약간의 지연을 허용하면 read 테이블을 보고 그런식으로 할 것 같다..는 과거의 나ㅋㅋ)

+ 후에 실습을 해보니 write -> read 로 이벤트 전파가 거의 동시에 이루어지는 것을 확인할 수 있었다. 다만 실 운영 환경에서는 트래픽이나 시스템의 환경에 따라 약간씩 다르지 않을까 생각된다.

참고

https://threedots.tech/post/basic-cqrs-in-go/

https://www.youtube.com/watch?v=qJA6MaQ90YY 

JAVA $JAVA_OPTS -jar $HOME/was/*.jar 1> $HOME/logs/server.log 2>&1 &

위 스크립트에서 &가 없으면 실행시킨 화면에서 실행이되고, 그 곳을 빠져나가면 shutdown 된다.

배포 쉘에 항상 저렇게 쓰는데, 매번 까먹어서 정리

• & : executes the first command in the background, The shell does not wait for the command to finish, and the return status is 0.
• && : executes the first command and conditionally proceeds to the second if it exits with success
• nohup : A background process(&) will not stay alive after the shell session is closed. Nohup makes running after you disconnect from the session. sh file should has 755 permission. nohup file will be created with debig info.
• > : redirection

참고

https://joonyon.tistory.com/98

저번 글에 sonarqube와 깃헙을 연동하다 권한문제로 포기아닌 포기를 했는데.. 

로컬에 설정을 하면서 아래와 같은 환경설정을 하여 소스 검증과 성능 테스트 환경을 구축하고 싶어졌다.

0. vm에 필요한 프로그램 설치

2022.01.10 - [세팅/vm on mac] - [vm] jenkins 설치

1. github secret 생성

2. jenkins 에서 github 계정 추가

3. sonarqube 설정 변경

4. github - sonarqube 설정

5. 프로젝트 구성

gradle build -> 실행 부분이랑

소나큐브 옵션 부분 추가해야한다.

6. 젠킨스 실행

jar 실행을 vm의 hangame 계정에서 실행하고 싶어서 추가작업 진행

1. node 등록 -> 노드는 사용하지 않았다.

노드 등록 후 아래와 에러가 났다.

/var/lib/jenkins/.ssh/known_hosts [SSH] No Known Hosts file was found at /var/lib/jenkins/.ssh/known_hosts. Please ensure one is created at this path and that Jenkins can read it.

/var/lib/jenkins/.ssh/known_hosts 해당 경로와 파일을 만들어준다.

2. 추가 플러그인 설치(이게 플러그인인줄 몰랐다. 매번 쓰던 옵션이 안나와서 당황..)

3. 설치 후 계정 추가하고

4. 구성에서 추가

centos7 에서 설치

> wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo
> rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key
> yum upgrade
> yum install epel-release java-11-openjdk-devel
> yum install jenkins
> systemctl daemon-reload
> systemctl start jenkins

포트 변경(기본 8080)

sudo vi /etc/sysconfig/jenkins
/PORT 검색 후 8888로 변경

systemctl restart jenkins

설치 후 ui로 들어가서 jenkins setup wizard를 진행하다보니 다음과 같은 에러가 나서 추가적인 설정을 하였다.

"Unable to connect to Jenkins Server." 

//Add Jenkins user to root group
sudo usermod -a -G root jenkins

vi /etc/sysconfig/jenkins
//아래 내용 수정
JENKINS_LISTEN_ADDRESS="0.0.0.0"

systemctl restart jenkins

ui에서 localhost:8888로 들어온다. secret key로 로그인 하고 기본 플러그인으로 설치하겠다고 하면 천천히 설치하면서 아래와 같은 화면이 된다.

우선 continue 누르고 세부 설정으로 넘어간다.

Jenkins 관리 > System Configuration

1. 자바

jdk11 은 기본 인스톨러에 없어서 아래와 같이 설정

2. 그래들 - 7.3.3. 으로 기본 인스톨러로 설치

3. 소나큐브 - plugin으로 설치

4. git 은 수동으로 설치

yum install git

목표: local vm sonarqube, github, springboot2.5 소스를 푸시할 때(혹은 pr) 깃헙에서 소나큐브 검사하도록 설정

준비사항: 아래 글의 build.gradle이 적용된 소스

2022.01.06 - [세팅/sonarqube] - [sonarqube] springboot2 + gradle

github action을 이용하여 sonarqube를 자동화 할 것이기 때문에, github action work flow를 만들어줘야한다.

그런데.. 회사 레파지토리에 action 탭도 없고.. settings에도 secret을 만드는 탭 자체가 없다..

좀 찾아보니.. admin role이 아니어서 그렇다는 말이 있다.

당장 관련 롤을 얻을 수 없어서 외부 개인 github에 임시 레파지토리를 만들어 테스트해보기로 한다.

1. 소스의 폴더 내에 .github 폴더를 만들고 그 안에 workflows라는 폴더 생성, 그 안에 yml형식의 파일을 만들어 workflow를 정의한다.

참고한 블로그

https://velog.io/@ggong/Github-Action%EC%97%90-%EB%8C%80%ED%95%9C-%EC%86%8C%EA%B0%9C%EC%99%80-%EC%82%AC%EC%9A%A9%EB%B2%95

https://zzsza.github.io/development/2020/06/06/github-action/

관련 내용을 참고하면서 내 프로젝트에 yml 파일을 만들었다.

1-1. yml을 만드는데 자꾸 형식이 틀렸다고 나와서 여기에 몇 시간을 투자했다..

매번 푸시하고 보기 힘들어서 아래 사이트에서 yml 검증하고 진행하였다..

http://www.yamllint.com/

1-2. 그렇게 통과한 나의 yml

name: be-sonar-test

on:
  push:
    branches:
      - master
      - develop
  pull_request:
    branches:
      - master
    # pr이 생성 되었을 때, 담당 유저가 등록되었을 때, PR에 코드가 머지되었을 때, 라벨이 달렸을 때 동작
    types: [opened, assigned, synchronize, labeled]

# 실행 해야할 job
jobs:
  # Job의 이름, 자유롭게
  analysis:
    runs-on: ubuntu-latest
    # 이 Job에서 사용할 환경변수
    env:
      # KEY - VALUE
      SONARQUBE_ID: admin
      SONARQUBE_URL: ${{ secrets.SONARQUBE_URL }}
      PR_NUMBER: ${{ github.event.pull_request.number }}
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Sonarqube Analysis
        run: |
          ./gradlew sonarqube
          -Dsonar.host.url=${{ env.SONARQUBE_URL }}
          -Dsonar.projectKey=${{ env.SONARQUBE_ID }}
          # project의 제목을 {프로젝트명}-{pr번호} 형식으로
          -Dsonar.projectName=${{ env.SONARQUBE_ID }}-${{ env.PR_NUMBER }}
          -Dsonar.login=${{ secrets.SONARQUBE_ACCESS_TOKEN }}
      - name: Comment Sonarqube URL
        uses: actions/github-script@v4
        with:
          # 이슈에 코멘트를 달아주는 스크립트 실행
          script: |
            const { SONARQUBE_ID, SONARQUBE_URL, PR_NUMBER } = process.env
            github.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `📊 ${ SONARQUBE_ID }-${ PR_NUMBER } 분석 결과 확인하기 [링크](${SONARQUBE_URL})`
            })

1-3. secrets 로 시작한 변수들은 github에서 생성하였다.

2. 마스터에서 푸시하면 자동 빌드하도록 했기에,, 푸시만 해도 아래와 같이 자동으로 시도한다.

3. 결론적으로 실패했다. 그 이유는 아래와 같다.

나의 소나큐브는 내 노트북에 있고, 깃헙은 완전 외부다보니 깃헙 -> 소나큐브로 접속이 불가하다.. 게다가 회사 노트북 & vpn 사용이라 공인 ip도 모르겠다. 

몇 시간 투자했는데 정작 네트워크 이슈로 끝을 못봐서 허무하다.. 네트워크에 대한 미래를 내다보지 못한 나의 무지함 때문이겠지ㅠ

제일 좋은 건 깃헙/소나큐브/(젠킨스) 까지 같은 망에 설치해서 하는 것인데 이래서 사람들이 도커로 다 올려서 하나보다. 나처럼 몇 개는 리얼 몇 개는 내부 서비스를 연동하려면 이런 네트워크 문제가 생길 수 밖에 없을 듯 하다.

이 내용과 별개로 github actions를 활용하면 깃과 관련한 많은 일을 자동화 할 수 있나보다.

커밋, 풀, 푸시 밖에 안해본 나로서는 매우 신기한 글이었다.

https://devblog.croquis.com/ko/2020-11-06-1-using-github-actions/

이전 글에서 깃헙과 소나큐브의 연동을 시도했으나 현재는 보류중이다.

찾아보니 제일 많이 연동하는 방법은 깃헙-젠킨스-소나큐브 이렇게 연동하여 젠킨스 빌드 시 소나큐브 실행 :: 이런 것 같은데 잘 모르는 상태에서 섣불리 젠킨스까지 건들이고 싶지 않아서 우선은 깃헙과 직접 할 수 있는지 알고 싶었다.

사실 상상한 것은 깃헙과 연동하면 소나큐브 화면에서 프로젝트를 고르고 각 프로젝트 별로 취약점을 볼 수 있을까 였는데, 그건 그냥 상상뿐인 것 같다는 생각을 했다..(어찌보면 말도 안되는 원리닼ㅋ)

그래서 소나큐브 맛보기로 소스에서 직접 연동해보기로 한다.

목표: java11 / springboot2.5 / gradle 사용 중인 프로젝트에 직접 연결

https://jeeneee.dev/springboot/springboot-2-introduction-of-sonarqube/

위 블로그를 참고하여 진행하였다.

1. 소나큐브에 로그인 엑세스 토큰을 받고

2. 아래와 같이 build.gradle 파일을 수정한다(수정한 부분만 작성).

plugins {
	...
	id 'org.sonarqube' version '3.3'
	id 'jacoco'
}

...

dependencies {
	...
	implementation 'org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:3.3'
}

test {
	...
	finalizedBy 'jacocoTestReport'
}

...

jacoco {
	toolVersion = "0.8.7"
}

jacocoTestReport {
	reports {
		xml.enabled true // sonarqube 분석에 필요한 xml파일만 생성
		csv.enabled false
		html.enabled false
	}

}

sonarqube {
	properties {
		property "sonar.host.url", "http://localhost:9999"
		property "sonar.login", "{login token}"
		property "sonar.sources", "src"
		property "sonar.language", "java"
		property "sonar.sourceEncoding", "UTF-8"
		property "sonar.profile", "Sonar way"  // 소나큐브에서 적용할 프로필(분석할 수준 설정)
		property "sonar.java.binaries", "${buildDir}/classes" // 자바 클래스 파일위치
		property "sonar.test.inclusions", "**/test/**"  // 코드 분석에 사용할 테스트 소스
		property "sonar.exclusions", "**/resources/**, **/Q*.class, **/test/**"  //테스트커버리지에서 제외할 파일, 예제에선 정적 js 파일과 queryDSL Q파일 제외
		property "sonar.coverage.jacoco.xmlReportPaths", "${buildDir}/reports/jacoco/test/jacocoTestReport.xml" // jacoco 플러그인의 결과파일
	}
}

3. 위와 같이 수정하고 gradle sonarqube 실행하니 빌드가 진행된다.

빌드 완료되었다는 문구를 보고 소나큐브 화면을 리프래시 해본다.

아까는 나오지 않은 프로젝트가 뜬다. 클릭하면 상세 설명이 나온다.

4. 인텔리제이 플러그인만 써도 이 정도는 어찌저찌 볼 수 있을 것 같은데, 굳이 서버를 깔아서 보는 것의 장점이라면 (편한 ui와 더불어) 바로 히스토리 관리가 아닐까 싶다.

위에서 나온 버그 2건을 수정하고 빌드(4:26), sysout을 더 찍고 빌드(4:47)의 과정을 거쳤다.

이렇게 빌드마다 버그의 갯수를 그래프로 보여주어 흐름을 한눈에 알 수 있다.

참고

github 연결

https://velog.io/@sihyung92/how-to-apply-sonarqube

결과 json / 파싱 

https://ghostitm.tistory.com/55?category=903890 

목표: 로컬 vm sonarqube - 회사 github 연동

로컬에서 소나큐브를 띄우고 로그인 후 아래 설명대로 깃헙과 인테그래이션을 진행하였다.

https://docs.sonarqube.org/latest/analysis/github-integration/

회사 깃헙 계정에서도 github apps 라는 걸 생성해야 연동이 가능했기에, 위 안내대로 생성했고, 연동완료하였다.

그리고 기대를 가득 안고 from github을 클릭하는데..

organization을 못찾는다며 githup app 에 organization 이 install되었는지 확인하란다.. 무슨말인지는 모르겠지만 다시 보니 이런 메뉴가 있다.

ㅠㅅㅜ 아마 저기서 install을 누르고 승인을 받아야 하는 것 같은데, install은 눌렀으나 누가 승인을 해주는지 모르겠다..

관련 시도는 아래 글에서 이어진다.

2022.01.07 - [세팅/sonarqube] - [sonarqube] github 연동 - 2

목표: vm centos7에 postgresql-14 / sonarqube Community 9.2.4 설치

0. vm 복제 및 서버 준비

1. 사전 서버설정

https://docs.sonarqube.org/latest/requirements/requirements/

# sysctl -a //시스템 변수 확인

# sysctl -w vm.max_map_count=524288
# sysctl -w fs.file-max=131072

# ulimit -n 131072
# ulimit -u 8192

2. 설치

가. postgresql

# yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
# yum install -y postgresql14-server postgresql14-contrib

# /usr/pgsql-14/bin/postgresql-14-setup initdb
//postgres 계정 생성됨

# sudo systemctl enable postgresql-14
# sudo systemctl start postgresql-14

# su - postgres

$ psql
postgres=# create user sonarqube with password 'sonarqube'; 
postgres=# create database sonarqube owner sonarqube;
postgres=# ALTER ROLE sonarqube WITH createdb; 
postgres=# GRANT ALL PRIVILEGES ON DATABASE sonarqube TO sonarqube;
postgres=# \q

$ vim /var/lib/pgsql/14/data/postgresql.conf
//주석해제 및 수정
listen_addresses = '*'
 port = 5432


$ vim /var/lib/pgsql/14/data/pg_hba.conf
//맨 아래 추가
> host all sonarqube 0.0.0.0/0 md5

# systemctl restart postgresql-14

나. sonarqube

# adduser sonarqube
# su - sonarqube

$ wget https://binaries.sonarsource.com/Distribution/sonarqube/sonarqube-9.2.4.50792.zip
$ unzip sonarqube-9.2.4.50792.zip
$ cd sonarqube-9.2.4.50792/conf
$ vim sonar.properties
//주석제거 및 수정
 sonar.jdbc.username=sonarqube
 sonar.jdbc.password=sonarqube
 sonar.jdbc.url=jdbc:postgresql://localhost/sonarqube

$ cd ../bin/linux-x86-64
$ ./sonar.sh start

실행하고 로그를 확인했더니 아래와 같이 에러가 발생하였다

//es.log
2022.01.05 15:30:00 ERROR app[][o.s.a.p.EsManagedProcess] Failed to check status
org.elasticsearch.ElasticsearchException: java.util.concurrent.ExecutionException: java.net.ConnectException: 연결이 거부됨
        at org.elasticsearch.client.RestHighLevelClient.performClientRequest(RestHighLevelClient.java:2695)
        at org.elasticsearch.client.RestHighLevelClient.internalPerformRequest(RestHighLevelClient.java:2171)
        at org.elasticsearch.client.RestHighLevelClient.performRequest(RestHighLevelClient.java:2137)
        at org.elasticsearch.client.RestHighLevelClient.performRequestAndParseEntity(RestHighLevelClient.java:2105)
        at org.elasticsearch.client.ClusterClient.health(ClusterClient.java:151)
        at org.sonar.application.es.EsConnectorImpl.getClusterHealthStatus(EsConnectorImpl.java:64)
        at org.sonar.application.process.EsManagedProcess.checkStatus(EsManagedProcess.java:97)
        at org.sonar.application.process.EsManagedProcess.checkOperational(EsManagedProcess.java:82)
        at org.sonar.application.process.EsManagedProcess.isOperational(EsManagedProcess.java:67)
        at org.sonar.application.process.ManagedProcessHandler.refreshState(ManagedProcessHandler.java:220)
        at org.sonar.application.process.ManagedProcessHandler$EventWatcher.run(ManagedProcessHandler.java:285)
Caused by: java.util.concurrent.ExecutionException: java.net.ConnectException: 연결이 거부됨
        at org.elasticsearch.common.util.concurrent.BaseFuture$Sync.getValue(BaseFuture.java:257)
        at org.elasticsearch.common.util.concurrent.BaseFuture$Sync.get(BaseFuture.java:244)
        at org.elasticsearch.common.util.concurrent.BaseFuture.get(BaseFuture.java:75)
        at org.elasticsearch.client.RestHighLevelClient.performClientRequest(RestHighLevelClient.java:2692)
        ... 10 common frames omitted
Caused by: java.net.ConnectException: 연결이 거부됨
        at java.base/sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
        at java.base/sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:777)
        at org.apache.http.impl.nio.reactor.DefaultConnectingIOReactor.processEvent(DefaultConnectingIOReactor.java:174)
        at org.apache.http.impl.nio.reactor.DefaultConnectingIOReactor.processEvents(DefaultConnectingIOReactor.java:148)
        at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:351)
        at org.apache.http.impl.nio.conn.PoolingNHttpClientConnectionManager.execute(PoolingNHttpClientConnectionManager.java:221)
        at org.apache.http.impl.nio.client.CloseableHttpAsyncClientBase$1.run(CloseableHttpAsyncClientBase.java:64)
        at java.base/java.lang.Thread.run(Thread.java:829)

ERROR: [2] bootstrap checks failed. You must address the points described in the following [2] lines before starting Elasticsearch.
bootstrap check failure [1] of [2]: max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535]
bootstrap check failure [2] of [2]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

1번에서 사전 설정한 내용과 겹치지만.. 우선 에러가 나니 root계정에서 설정 값을 변경해보았다.

1. /etc/security/limits.conf

vi /etc/security/limits.conf
//아래 내용 추가
root   soft    nofile    65536
root   hard    nofile    65536
sonarqube   soft    nofile    65536
sonarqube   hard    nofile    65536
     
# End of file

2. 변수 값 변경(elastic 이 돌기 위한 설정 값으로 변경)

sysctl -w vm.max_map_count=262144

위와 같이 수정을 하고나니 같은 에러는 안나는데, 다른 에러가 난다.

용량이 없나보다.

//web.log
Caused by: java.nio.file.FileSystemException: /home/sonarqube/sonarqube-9.2.4.50792/lib/extensions/sonar-scala-plugin-1.8.3.2219.jar -> /home/sonarqube/sonarqube-9.2.4.50792/data/web/deploy/plugins/sonarscala/sonar-scala-plugin-1.8.3.2219.jar: 장치에 남은 공간이 없음

아니 8기가 배정에 벌써 6기가를 다 써버렸다니.. 충격과 공포다.. 아무래도 다시 세팅해야 할 것 같다..

[root@localhost ~]# df -h
Filesystem               Size  Used Avail Use% Mounted on
devtmpfs                 2.4G     0  2.4G   0% /dev
tmpfs                    2.4G   28K  2.4G   1% /dev/shm
tmpfs                    2.4G  9.2M  2.4G   1% /run
tmpfs                    2.4G     0  2.4G   0% /sys/fs/cgroup
/dev/mapper/centos-root  6.2G  6.2G   18M 100% /
/dev/sda1               1014M  226M  789M  23% /boot
tmpfs                    480M  8.0K  480M   1% /run/user/42
tmpfs                    480M     0  480M   0% /run/user/0

..후기.. 

다음 날 32기가로 다시 세팅해서.. 결국 보았다. ui를!!

참고

https://www.fosslinux.com/24429/how-to-install-and-configure-sonarqube-on-centos-7.htm

목표: vm에 jar을 배포한다. jar 이 정상 실행되려면 보안상의 이유로 host의 ip를 사용해야한다. jar이 정상 실행되면 host에서 vm의 api를 쏠 수 있어야 한다.

1. NAT 방식

2022.01.03 - [세팅/vm on mac] - [vm] virtual box 네트워크 NAT 설정 - mac

호스트의 ip를 게스트가 그대로 사용하는 방식으로 vm 내부의 jar가 정상작동한다. 하지만 host -> vm로 api shoot이 안된다. 

포트 포워딩으로 jar의 port를 설정해주었지만 telnet 은 되고 curl을 할 경우 connection reset으로 response 를 받아오지 못한다.

포트 포워딩으로 해결할 수 있을 것 같아 계속 보고있다ㅠㅠ

-> 포트 포워딩 설정에는 문제가 없었다!! 게스트에서 방화벽 정책 끄니까 된다...

systemctl status firewalld  //상태 확인
systemctl stop firewalld    //종료

2. Bridge adaptor

2022.01.12 - [세팅/vm on mac] - [vm] virtual box 브릿지 네트워크 설정

게스트에 별도 ip를 할당받아 보안정책에 의해 jar 실행이 되지 않는다.

참고 - 네트워크 개념 팍팍팍..

https://www.nakivo.com/blog/virtualbox-network-setting-guide/