nextcloud, 분노, helm, homeserver

홈서버운영한지 xx년차 – k3s서버 helm으로 관리하면서 열받아서

  1. 쌩으로 설치해서 쓰다가
  2. docker-compose로 쓰다가
  3. docker swarm으로 쓰다가
  4. k3s로 쓰는중인데

1,2,3은 다 좋았는데 k3s로 가면서 문제가 많이 생긴다
애플리케이션 그냥 실행시키던 시대엔 대부분 php라서 apache에 연결해서 실행시켰고
자바계열은 ajp연결했고

Docker는 가장 편했다. 이미지도 대부분 잘 만들어져 있어서 env만 잘 넣으면 실행이 됐다.
간혹 volume으로 설정파일을 넣어야 하는 경우가 있긴하다..
이걸 docker-compose로 만들고 apache, nginx로 vhost라우팅

docker-swarm도 traefik연결하는게 좀 삽질이 심했지만 안정화 이후엔 편안했다

K3s 문제들

ingress

ingress는 복잡하고 어렵긴한데 익숙해지면 어떻게든 할만하다

이상하지는 않다.

차트의 문제

helm차트는 좀처럼 쓸만한게 없다.
artifact.io에서 검색해서 쓰는데 얼마 나오지도 않고
오피셜도 제대로 안 돌아가는게 많다.

bitnami가 그나마 나은편이데 중간중간 함정이 있다.
잘 안된다싶으면 내가 잘못한게 아니고 차트가 잘못됐음을 빨리 인정하고 다른걸 찾던가 새로 만들거나 적당히 고쳐 써야야한다

Docker 함정 빈도가 10%정도라면
Helm은 함정 빈도가 30%정도 된다

helm의 기능문제

차트가 완벽하면 좋은데 다 조금씩 모지란 새끼들이다
그렇다고 완전히 새로 만들기는 시간이 너무 낭비되고 조금만 고쳐 쓰고싶다

잘못된 telmplate파일만 오버라이딩해서 쓸 수 있으면 좋겠는데 그런건 지원되지 않는다.

오버라이딩이 되어야오피셜 차트버전업 혜택을 보면서 나한테 맞게 커스터마이징 해서 쓸 수 있는데… 아예 복붙해서 만들거나 대강 알아서 써야한다.

해결방법으로 겨우 만든게

helmsman으로 하위디렉토리에 차트를 넣고

/chart.d
  /nginx
  /nextcloud
  /postgres
chart_override.d/
  /nginx
  /nextcloud
  /postgres
helmfile.yaml
init.sh

이런식으로 놓고 init.sh를 실행할 때 마다 chart를 새로 받아서 chart.d에 압축을 풀고
chart_override 디렉토리에서 그냥 덮어씌워 복사하게 만들어서 썼는데
잘 되긴하는데… 뭔가 기분나빠서 관뒀다

덮어씌우기 복사하는거라서 잘못된 파일을 빼는건 안된다.
빈 파일로 덮어띄우던가 삭제하는건 따로 만들어야할듯

문제의 차트 nextcloud helm

설정이 중간중간 잘못 돼 있다
values.yaml만 가지고 모든걸 컨트롤 하려다보니 이런 문제가 발생하지 않았을까

helm차트를 bitnami, truechart등 한곳에서 여러개를 만들다 보니
공통패턴으로 활용하는데 과도하게 집착하는 것 같고…
그것때문에 오류가 나는 경우가 조금 보인다

helm도 깔끔하게 상당부분 수동으로 하도록 해야한다.
어차피 개별 오픈소스 도커이미지가 제각각이라 별 수 없고 공통적인 설정같은건 불가능하다

결국 환경변수 도 이런식으로 제각각이잖아
MYSQL_DATABASE, POSTGRES_DB

deployment.yaml만 수정하니 쓸만해졌다
설정파일을 사용하는 버전으로 완전 수정할까 했는데
그냥 잘 되서 그만뒀다

결론

helm차트에서 뭔가 잘 안되면 folk해서 적당히 수정해서 써야한다.

굉장히 높은 확률로 내가 잘못한게 아니라 차트가 잘못됐다.

도커이미지는 그나마 오피셜로 관리가 되는데 helm은 뭔가 애매하다.
예전 ansible이나 chef마냥 버전지원이 제대로 안되는 느낌..
예전에 ansible, chef와 비슷하다. 차트(레시피)를 바닥부터 다 새로 만들어야될 정도로 공개된 것 중에 쓸만한게 없었다. 때마침 컨테이너 기술이 활성화 되기도 했고

너, 자바충이지? – 자바에 중독된 뇌를 고쳐라 1

뇌가 자바에 절여진 자바충들아 자바를 버려라

코틀린이라는 압도적인 솔루션이 나왔음에도 자바만을 고집하는 어리석은 자바충들이 이제라도 코틀린으로 넘어오길 바라며

자바충 특

  • 자바 버전올라가는거 싫어함
  • log4j 뉴스나오기 전까지 업데이트 안함
  • stream()쓰면 안되는 줄 앎
  • 리플렉션 쓰는거 싫어함

자바에 비해 코틀린은 문법이 유연하다

Entity to DTO코드 만들기 비교

자바충

엔티티 클래스에 public AccountDto toDto()
를 만들어서 꾸역꾸역 쑤셔넣는다
Entity, Dto가 상호 참조를 유지해야되서 좆같이 한 모듈에 쑤셔쳐박는다

코틀린 사용자

fun Entity.toDto()
으로 재미있게 만들 수 있고

  • presentation
  • service
  • model

그레이들 모듈로 레이어를 나눠서 사용하고 수 있다.
모듈화로presentation 레이어에서 Entity에 손도 못 대게 만들어둘 수 있다.

왜좋은지자세한설명은서버용량이부족해서생략
용량이부족해서띄어쓰기도생략

인도에서는 19단까지 외운다며?

표현의 풍부함은 사고의 프레임워크를 확장시켜준다

자바충의 사고방식에서 [1,2,3,4,5,6,7]에서 홀수를 꺼내려면 어떻게 해야할까?
더러워서 여기 쓰기도 싫다

kotlin way

fun filterOdd(input) = input.filter{ it % 2 != 0 }

apply, let, also, with, run, filter, sum, map 등등 처음엔 헷갈리는데
외워놓다보면 표현식이 점점 익숙해지면서 쓸데없는 부분에서 오버헤드가 사라진다.
못 외울정도는 아니기도 하고

null <> “”

아무리 자바충이라도 설마

null ? !!

귀찮다

EOF