Chef
Vagrant
Puppet
Ansible
https://cloud.google.com/solutions/google-compute-engine-management-puppet-chef-salt-ansible
https://brunch.co.kr/@jiseon3169ubie/2
https://xebialabs.com/the-ultimate-devops-tool-chest/provisioning-config-management/
장단점 비교는 아직
.. 제대로 못써봐서
git(prg) – read
git(dev) – read, write
접근 권한을 나눠서 배포시스템에는 읽기만 허용
다음과 같이 환경을 구성하고
여기에 맞춰서 devops 구성을 하면 된다.
개발환경
Vagrant, Docker등 활용해서 환경구성
각자 DB, MQ 구동
동일 DB, MQ 구동
idc, cloud 환경
product 배포전 테스트
확인 후 인스턴스 종료
product실제서버 batch인스턴스 이외에는 항상동작
rvm보다 가볍고 시스템에 영향을 주지 않는다(삭제하기쉽다)는 이유로 rbenv으로 루비 버전관리 툴의 대세가 넘어간 것 같다.
http://rvm.io 접속해서 스크립트로 설치
설치는 좀 더 성가시다.
공식 주소 :
https://github.com/rbenv/rbenv
install명령을 쓰려면 이것도 깔아줘야한다 :
https://github.com/rbenv/ruby-build
$ 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
설치 $ rbenv insall 2.3.3 버전확인 $ rbenv versions 버전선택 $ rbenv global 2.3.4 버전확인 $ ruby -v
MSA는 API를 이용해 통신을 한다.
그런데…. 의존성이 생기니까 관리가 힘들다.
버전관리가 필요.
의존성이 있는 모든것을 동시배포
그냥 전체배포라고 보면 된다.
* 서비스가 작을 때 가능
* 오류가 나면 매우 난감함
* DB스키마가 변경됐을 가능성이 크기 때문에 rollback도 쉽지가 않다.
컨트롤러, 라우터 등등에서
/v1/
/v2/
이런방법으로 버전을 표시
* 버전업이 자주 발생하면?
* 헷갈리겠지
jenkins, git-tag, docker, kubernetes 등등 사용해서 해결할 수 있는 부분
해놓으면 편하긴 하겠지만… 구현자체가 복잡하다.
어떻게 배포를 해도 오류가능성이 존재하겠지만… 관리가 쉬운편이 더 낫지 않을까
적절한 방법을 골라서 정책을 정하고 지키는게 중요.
API Doc은 Hunam, Machine – 두가지 버전이 필요하다.
swagger
Hataoes
그리고 json형태의 doc???
에러로깅 방식..??
등 지원
build runtime 버전 check
의존성 api들을 모두 기록해놓는다.
depends on – (auth-1.1)
depends on – (gis-201610)
….
기록해놓은 부분은 내가 참조했 버전이 맞는지 버전만 호출해서 확인.
의존성이 있는 MS들의 test 인스턴스가 떠있거나
docker-compose, kubernetes 등으로 관리되고 있어야 가능한 부분.
아닌가.. 버전만 확인하니까 git 주소만 알아도 가능할 것 같다.
유닛테스트일수도 있는데 좀 더 강하게 빌드시 확인을 해야한다.
요즘엔.. SSO 관련 개발은 거의 필수인데
막상개발하려면 여기저기 다 있는거 또 만드는 것 같은 생각이 들지만…
오픈소스나 뭐 갖다 쓰려고 하면 또 마땅한게 없다.
JOSSO : 설치하면 실행된다. 쉽게 사용은 가능한데 커스터마이징도 쉬울까가 고민..
CAS : 코드가 매우 복잡.. 잘 이해가 안간다. 새로 만드는게 더 빠르지 않을까? 그냥 실행되는것도 아니라서 갖다쓰기도 편하지 않다.
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를 구현했는데…
좀 개선해보려면 어떻게 하는게 좋을지
멱등성 관련 : http://memo.polypia.net/archives/2505
JWT참고
http://bcho.tistory.com/999
https://jwt.io/
https://blog.outsider.ne.kr/1160
Claim기반 호출
HMAC을 이용한 보안
PPK필요
JWT을 적용해서 쓴다면 대략이정도 느낌이 되면 될것같다.
gradle, maven 테스트, 배포 타이밍에 적절한 조치가 필요할 것 같다.
local에서 할 때는 auth가 제역할을 못해줄 것 같으니
auth서버도 push를 하려면 ppk(auth-ppk)가 있어야하고 ResourceProvider은 auth-ppk(public key)를 가지고 있어야한다.
종이에 그릴땐 간단해보였는데 다시보니 좀 복잡해보인다. 좀 더 간소화 필요.
rest api 사용할 때 관련있는 api의 목록을 제공한다는 컨셉
참고 :
https://spring.io/understanding/HATEOAS
https://en.wikipedia.org/wiki/HATEOAS
그런데… 근본적으로 이해가 안간다.
보통 뭔가 기술적으로 정립된것들을 보면 나도 필요하다고 생각했던 경우가 많은데
이건 왜 스는건가 의아하다
이건 도큐먼트 아닌가
기계가 알아봐야하는 도큐먼트
generated doc의 일종이 되어야 할 것 같다.
/rest/api/user
/rest/doc/user
와 같은 관계가 되야하지 않을까
일단 비관적이고
뭔소린지는 알겠는데 공감이 가지 않는다.
안쓰겠다.
부하분산 방법
MSA
하드웨어방식 vs 소프트웨어 방식
예전에는 L4하드웨어방식만 썼는데 클라우드. 그리고 글로벌화되면서 상황이 좀 바뀌었다.
L4
좋기야 하지.. 그런데 비싸다.
예전에는 많이 썼는데 요즘은??
클라우드에서도 L4를 지원해주긴하는데
속에서 몰래 소프트웨어방식으로 처리하는거 아닐까
안해봤는데 될것같아
많이쓰는방법
호출뻑할때가 많은데
멱등성이 필요할때가 많다.
unique조건. id값은 오차가 생길 수 있지만 unique를 활용하면 어느정도 처리할 수 있지 않을까
완전히 같을수는 없고
대신에 비슷한 요청이 올 때 update가 돼 버릴 수도 있다.
이게 상관없다면 이렇게 그냥 하는것도 괜찮지 않을까
상관없는 경우도 많으니
ajax호출이나 client에서 호출하는경우에 특히 중복호출이 많으니…
async로 한다면 더 심할 수 있다.
처리소요시간에 따라 적정 딜레이가 도움이 될 수도 있겠다.
cache처리하는것처럼 dynamic하게 관리되면 될 것 같다.
응답시간이 평균 5초정도라면 3초안에 중복요청은 무시해버리는식으로
사람이 많을때 서버성능을 향상시키는데도 도움이 될 것 같다.
설계는 다음에
