Tiller 없어짐
차트 리포지터리 검색
로컬과 helm hub 모두 동작? 항상 웹으로 찾아가지고 몰랐던 부분
의존성관리
Chart.yaml에서 의존성 관리. requirements.yaml을 포함. 용어도 변경 requirements -> dependencies
helm2 하위호환 보장
차트의 type 추가 – application / library
주요 명령어 기능변화
uninstall 하면 기본값이 purge라던가… helm2까지 많이 사용하던 사람 아니면 관심가질 필요 없는 내용.. 어차피 쓰다보면 알게되는
갑자기 떠올랐다고 해야되나.. 내가 갑자기 알게된건가
AWS서밋2018 가서 보고 이게 이렇게 핫한 기술이라는걸 알게 됐다.
컨테이너 기반 개발/배포에 어느정도 익숙해져 갈 즈음이라… 이게 왜 필요한지 잘 이해가 안 갔었달까
(뭐 그냥 로그수집 할 때나 쓰면 적당하겠군)
그런데 최근 파일업로드 서버를 만들다가 갑자기 생각이 들었다.
여기다가 쓰면 되는거구나…
한번 생각나고 나니까 여기저기 적용할만한 구석이 보이기 시작한다.
역시 테스트가 필수적이다. 실서버에 배포를 하면 시간도 오래 걸리고, 돈도 들고, 운영중인 서비스라면 서비스가 중단된다.
로컬에서 빠르게 코딩-테스트할 환경이 필요한데
AWS, GCP 모두 테스트 환경을 제공 해 주고 있다.
로컬에 설치해서 개발이 가능한 솔루션도 많이 있다. 집에다가 한개 설치 해 놓고 개발용으로 써도 될 것 같다.
https://github.com/kubeless/kubeless
https://fission.io/
https://www.openfaas.com/
https://openwhisk.apache.org/
AWS는 다양한 언어를 제공 해 주고 있는 데 반해.
GCP는 아직 걸음마 단계… js만 사용가능하다.
kubernets 기반에 설치해서 사용이 가능한 fission도 있고
다른 서버리스 솔루션들을 kubernetes에 설치해서 써도 될 것 같지만….
그럴거면 그냥 컨테이너를 띄우지…
Serverless가 간편하다고 하지만.. SpringBoot나 다른기술들에 어느정도 익숙하다면 시간차이는 크지 않다.
AWS를 쓰면 구축 난이도가 좀 높은 API게이트웨이까지 사용할 수 있어서 더 좋을 것 같다.
AWS의존적인 시스템을 만들지 않으려고 했지만.. 이건 뭐 답이 없다. 그냥 의존적으로 가다가 문제가 생기면 빼는게 나을 것 같다.
로컬테스트는 이것저것 해보겠지만… 실 서비스는 AWS, API Gateway, DynamoDB/Aurora가 거의 확정.