Chef
Vagrant
Puppet
Ansible
https://cloud.google.com/solutions/google-compute-engine-management-puppet-chef-salt-ansible
https://brunch.co.kr/@jiseon3169ubie/2
The Ultimate List of Provisioning and Configuration Management Tools
Month: June 2017
Docker 배포관리시스템
배포시스템
장단점 비교는 아직
.. 제대로 못써봐서
Heroku
Dokku
Flynn
Kubernetes
Deis
Docker-Swarm
리포지터리 접근 등 기타설정
git(prg) – read
git(dev) – read, write
접근 권한을 나눠서 배포시스템에는 읽기만 허용
웹개발시 인프라 구성
다음과 같이 환경을 구성하고
여기에 맞춰서 devops 구성을 하면 된다.
1. dev
개발환경
Vagrant, Docker등 활용해서 환경구성
1-1 dev-local
각자 DB, MQ 구동
1-2 dev-remote
동일 DB, MQ 구동
2. real
idc, cloud 환경
2-1 real-stage
product 배포전 테스트
확인 후 인스턴스 종료
2-2 real-product
product실제서버 batch인스턴스 이외에는 항상동작
Ruby Version 관리 툴 – rvm.io rbenv
개요
rvm보다 가볍고 시스템에 영향을 주지 않는다(삭제하기쉽다)는 이유로 rbenv으로 루비 버전관리 툴의 대세가 넘어간 것 같다.
rvm
http://rvm.io 접속해서 스크립트로 설치
rbenv
설치는 좀 더 성가시다.
공식 주소 :
https://github.com/rbenv/rbenv
install명령을 쓰려면 이것도 깔아줘야한다 :
https://github.com/rbenv/ruby-build
ubuntu 17.04 desk
|
1 2 3 4 5 6 7 |
$ git clone https://github.com/rbenv/rbenv.git ~/.rbenv $ cd ~/.rbenv && src/configure && make -C src $ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc $ ~/.rbenv/bin/rbenv init 수동으로 추가해야할 수 있다. $ git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build |
|
1 2 3 4 5 6 7 8 |
설치 $ rbenv insall 2.3.3 버전확인 $ rbenv versions 버전선택 $ rbenv global 2.3.4 버전확인 $ ruby -v |
MSA서비스에서의 API
개요
MSA는 API를 이용해 통신을 한다.
그런데…. 의존성이 생기니까 관리가 힘들다.
버전관리가 필요.
버전관리 방법
동시배포
의존성이 있는 모든것을 동시배포
그냥 전체배포라고 보면 된다.
* 서비스가 작을 때 가능
* 오류가 나면 매우 난감함
* DB스키마가 변경됐을 가능성이 크기 때문에 rollback도 쉽지가 않다.
소스코드 내에서 버전을 관리
컨트롤러, 라우터 등등에서
/v1/
/v2/
이런방법으로 버전을 표시
* 버전업이 자주 발생하면?
* 헷갈리겠지
배포시 태깅
jenkins, git-tag, docker, kubernetes 등등 사용해서 해결할 수 있는 부분
해놓으면 편하긴 하겠지만… 구현자체가 복잡하다.
결론은…
어떻게 배포를 해도 오류가능성이 존재하겠지만… 관리가 쉬운편이 더 낫지 않을까
적절한 방법을 골라서 정책을 정하고 지키는게 중요.
MSA에 필요한 API Doc의 종류
Human – Machine
API Doc은 Hunam, Machine – 두가지 버전이 필요하다.
Human
swagger
Machine
Hataoes
그리고 json형태의 doc???
에러로깅 방식..??
등 지원
Versioning(API Change log doc)
- history
- plan
- deprecated 일정예고
- current
세가지 정보를 모두 표현해야한다
검증테스트
build runtime 버전 check
의존성 api들을 모두 기록해놓는다.
depends on – (auth-1.1)
depends on – (gis-201610)
….
기록해놓은 부분은 내가 참조했 버전이 맞는지 버전만 호출해서 확인.
의존성이 있는 MS들의 test 인스턴스가 떠있거나
docker-compose, kubernetes 등으로 관리되고 있어야 가능한 부분.
아닌가.. 버전만 확인하니까 git 주소만 알아도 가능할 것 같다.
유닛테스트일수도 있는데 좀 더 강하게 빌드시 확인을 해야한다.
SSO(SingleSignOn) – Solution vs 직접개발
개요
요즘엔.. SSO 관련 개발은 거의 필수인데
막상개발하려면 여기저기 다 있는거 또 만드는 것 같은 생각이 들지만…
오픈소스나 뭐 갖다 쓰려고 하면 또 마땅한게 없다.
대안
OpenSource
JOSSO : 설치하면 실행된다. 쉽게 사용은 가능한데 커스터마이징도 쉬울까가 고민..
CAS : 코드가 매우 복잡.. 잘 이해가 안간다. 새로 만드는게 더 빠르지 않을까? 그냥 실행되는것도 아니라서 갖다쓰기도 편하지 않다.
상용Commercial
직접개발
관련기술
SAML : 삼를.. 잘 모르겠다.
http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_roles_providers_saml.html
OAuth : 오앗. 토큰받아다가 쓰는거. 많이 쓰니까 설명생략
GlobalCookie : 여러서버에서 동일한 네임의 쿠키를 바라본다. auth서버를 호출해야겠지
IP : 접속주소
MacAddress : 랜카드 주소기반
LDAP : 디렉토리 서비스 계층형으로 권한을 저장하는방식??/정도로 알고있는데..
Token : Stateless 호출에 사용. API에 많이 사용됨
등등…
다 지원되면 좋겠지만 다 하기는 힘들고 필요한것만 사용하는게 좋다.
~~~~~
위의 기술을 그대로 구현할수도 있고.. 유사하게 구현할수도 있고..라이브러리를 갖다쓸 수도 있고
이전에 쓸 때는 OAuth서버를 구현하고 OAuth(Like)방식으로 내부 SSO를 구현했는데…
좀 개선해보려면 어떻게 하는게 좋을지
API호출방법 – RESTful -> 멱등성Idempotent -> Stateless -> JWT
개요
멱등성 관련 : http://memo.polypia.net/archives/2505
- RESTful API를 쓰다보면
- 멱등성이 필요하고..
- 그러려면 Stateless 해야하고
- 그러기위해 JWT(JSON Web Token)를 지원하면 좋다.
JWT간략
JWT참고
http://bcho.tistory.com/999
https://jwt.io/
https://blog.outsider.ne.kr/1160
Claim기반 호출
HMAC을 이용한 보안
PPK필요
PPK(PublicPrivateKey)를 이용한 API인증
JWT을 적용해서 쓴다면 대략이정도 느낌이 되면 될것같다.
gradle, maven 테스트, 배포 타이밍에 적절한 조치가 필요할 것 같다.
local에서 할 때는 auth가 제역할을 못해줄 것 같으니
auth서버도 push를 하려면 ppk(auth-ppk)가 있어야하고 ResourceProvider은 auth-ppk(public key)를 가지고 있어야한다.
종이에 그릴땐 간단해보였는데 다시보니 좀 복잡해보인다. 좀 더 간소화 필요.
Hateoas – 왜 쓰는거지
개요
rest api 사용할 때 관련있는 api의 목록을 제공한다는 컨셉
참고 :
https://spring.io/understanding/HATEOAS
https://en.wikipedia.org/wiki/HATEOAS
그런데… 근본적으로 이해가 안간다.
보통 뭔가 기술적으로 정립된것들을 보면 나도 필요하다고 생각했던 경우가 많은데
이건 왜 스는건가 의아하다
이건 도큐먼트 아닌가
기계가 알아봐야하는 도큐먼트
generated doc의 일종이 되어야 할 것 같다.
/rest/api/user
/rest/doc/user
와 같은 관계가 되야하지 않을까
일단 비관적이고
뭔소린지는 알겠는데 공감이 가지 않는다.
안쓰겠다.
Load Balancing
개요
부하분산 방법
MSA
하드웨어방식 vs 소프트웨어 방식
예전에는 L4하드웨어방식만 썼는데 클라우드. 그리고 글로벌화되면서 상황이 좀 바뀌었다.
DNS
L$
L4
좋기야 하지.. 그런데 비싸다.
예전에는 많이 썼는데 요즘은??
클라우드에서도 L4를 지원해주긴하는데
속에서 몰래 소프트웨어방식으로 처리하는거 아닐까
Iptables
안해봤는데 될것같아
HaProxy
많이쓰는방법
ApacheHttpd – Proxy
Nginx – Proxy
restful 멱등성이 지원되도록 한다면
호출뻑할때가 많은데
멱등성이 필요할때가 많다.
unique조건. id값은 오차가 생길 수 있지만 unique를 활용하면 어느정도 처리할 수 있지 않을까
완전히 같을수는 없고
대신에 비슷한 요청이 올 때 update가 돼 버릴 수도 있다.
이게 상관없다면 이렇게 그냥 하는것도 괜찮지 않을까
상관없는 경우도 많으니
ajax호출이나 client에서 호출하는경우에 특히 중복호출이 많으니…
async로 한다면 더 심할 수 있다.
처리소요시간에 따라 적정 딜레이가 도움이 될 수도 있겠다.
cache처리하는것처럼 dynamic하게 관리되면 될 것 같다.
응답시간이 평균 5초정도라면 3초안에 중복요청은 무시해버리는식으로
사람이 많을때 서버성능을 향상시키는데도 도움이 될 것 같다.
설계는 다음에