Monthly Archives: April 2017

DevOps 관련 정리

개요?

완전히 새로운 개념은 아니다.
기존에 개발자들이 하려고 하던 많은 노력들을 모아서 하나의 이름을 붙인 것 뿐.
DevOps에 따라붙는 몇가지 개념들

애자일, 마이크로서비스, 배포자동화

이런것들을 하기 위해서 필요한 기술들은.. 흔히 생각하던 것들
귀찮아서 안하지만
에러메세지, 테스트 …

팀 규모

피자2판 규칙 – 아마존
한팀의 인원을 2명으로 제한한다.

Docker 개념, 그리고 처음 프로젝트 적용 소감

도커 이미지로 동일한 환경을 구성하면

이 환경을 개발/테스트/운영 모두 동일한 환경에서 의존성 문제없이 사용할 수 있다.

동일환경 배포라는 문제를 해결하기 위해 등장한 도구들

  • 가상화 도구 : VMware, KVM, VirtualBox, HyperV
  • 클라우드 플랫폼 : OpenStack, CloudStack
  • 서버설정 자동화 : Puppet, Chef
  • 배포도구 : Capistrano, Fabric
  • 작업부하 관리 : Mesos, Fleet
  • 개발환경 설정 : Vagrant

도커와 함께 쓰이기도 하고 따로 쓰이기도 한다.

도커를 일주일정도 쓰면서 프로젝트에 적용하고나니 이제서야 감을 좀 잡겠다.
도커관련 책이 많이 나와있는데… 이걸 다 외울게 아니라면 한번훑어보고 넘어가는게 좋겠다.
명령어는 인덱스만 잡아놓고 그때그때 찾아서 쓰다보면 외워지는게 제일 나은것같다.

도커 개념을 잡으려면 먼저 써보는게 좋다.

일단 명령어 하나도 몰라도 윈도우/맥에서 쉽게 설치해서 쓸 수 있게 나와있다.
Docker(https://www.docker.com/)
GUI도구 (https://kitematic.com/)

도커의 아키텍처

리눅스의 컨테이너가 발달한 형태로
iptables, virtual bridge, cgroups, namespace.. 등의 커널매커니즘이 얽혀서 돌아간다.
(자세한 것은 리눅스커널을 먼저 이해해야 알 수 있을 것 같다.)

도커는 클라이언트, 서버데몬, 레지스트리로 나뉜다.

서버데몬이 우리가 생각하는 도커 컨테이너를 구동하는 녀석이고
docker 명령어를 친다고 생각하는게 클라이언트
레지스트리는 도커허브의 역할이다.
(자세한 것은 책에 잘 나온다)

도커 도구

도커 도구가 많이 나왔던 것같은데…
초기에 나온것들은 많이 정리가 됐는지 책에 나와있는것들도 바뀐게 좀 있는 것 같다.
최신 방법론은 도커 최신 공식문서를 찾아봐야 하지 않을까

활용법

도커 컨테이너는 쓰고버리는 1회용품으로 생각하면 쉽다.
영구적으로 저장하는 데이터를 여기 저장하면 안되겠지
API서버를 돌린다면 사용자 정보와 디비는 별도로 돌아가도록…
테스트에 한해서 DB를 돌리기도 한다. 저장경로를 컨테이너 외부로 잡으면 디비를 직접 돌려도 상관없지 않을까 싶기도 하지만… 디비를 업그레이드 하면서 파일이 깨질가능성도 생각해보면.. 좋은 생각은 아니다.

사용법

http://tutorial.polypia.net/w/Docker

설치방법

다운받아서 깔아도 되고 apt yum 등.. 자동설치 지원이 잘 된다.

사용후기

적용을 하려면 이해가 좀 필요할 것 같다.
그리고 도커에 맞춰서 아키텍처의 변형도 좀 필요해 보인다.
지금까지 gradle bulid 를 war로 만드는게 목표였다면
docker내에서 사용하는 방법은 좀 다를 수 있다.
docker이미지 내에 maven/gradle빌드환경을 구축 해 놓을수도 있고
docker하에서는 spring boot에서 기본옵션으로 사용하는 embedded was컨셉이 기존 별도 was실행하는 방식보다 더 적합해 보인다.
embedded하는게 spring boot가 꼭 필요하진 않지만…
어쨌든 오래된 자바 컨셉에 적합한 구조는 아니다. 도커에 맞춰서 설계를 새로 잡아야 할 것 같다. 설정파일 관리부터 많은 부분이 바뀌어야한다.

Java Template 엔진 – 텍스트

JSP – jstl

www가 html을 쓴다면,  jsp도 계속 쓴다
협업시 jsp를 쓴다면 깔끔한 코딩은 신경쓰지 말자
쑤셔넣어서 개발하기좋고 보통 그렇게 사용된다

Thymleaf

이메일 템플릿 용도로 써봤는데
잘 만들어놓으면 퍼블리셔가 자꾸 망쳐놓는다.
문법이 어려우니까…
디자이너 퍼블리셔 개발자 협업해서 쓰라고 만든 것 아닌가?
이정도면 용도폐기 수준.

다시는 쓸 생각이 없다.

Velocity

jstl에서 꺽쇠 쓰는걸 샵으로 대체하는 정도
그만 만들고 다른 생산적인 일을 했으면 좋겠다.

Freemarker

Velocity와 또 다른 끔찍한 혼종
뷰 코드에 베이직형태의 코드를 짜집어 넣고싶어 환장한 사람이 있다면 추천
아니라면 이걸 쓸 필요는 없지 않을까

Mustache

jquery tmpl 하고 비슷한 방식을 사용한다.
익히기 쉽고 사용도 쉽다.
눈에띄는 단점은 없는데 실제 프로젝트에 적용 해 보지 않아서 아직 뭐라 말을 못하겠다.
간단한 페이지에 적용 해 볼 의향이 있는 정도

Jade

노드랑 ㄷ장고 프로젝트 만질 때 좀 썼었는데
좋지도 나쁘지도 않았다.
익숙하지 않아서 그런지 모르겠지만 탭강간이 심각했다
탭이 대여섯개 넘어가면 파일을 나눈다거나 하는 별도의 노력이 필요하지 싶다.
자바용으로도 나와있다고 하는데 자바에서는 안 쓸 것 같고
노드 프로젝트 할 때나 써봐야겠다.

결론

은 HTML

결국 HTML을 뽑아낼 방법을 찾는 것들인데

뭐가 더 편할지는 취향차이가 있을 것이라고 생각한다.

물론 완전히 잘못된 선택도 존재한다.

Java Template 엔진 – Layout

JSP include

엔진이라고 할건없지만…

구성 잘 잡아놓고 쓰면 tiles나 sitemesh 못지않다.

 

Sitemesh

레이아웃을 잡고 콘텐츠만 바꿔먹을 때 써먹기 좋다.

그런데… 프로젝트 할 때 마다 이것저것 써보자 써보자 하는것도 아니고…

우선순위에서 밀리다 보니 안쓰게 된다.

 

Tiles

주로 사용하긴하는데…

좋은지는 잘 모르겠다.

다른 쓸게 없어서 쓴다는 정도 느낌

ignore=true 옵션을 켜놔도 스텍트레이스가 계속 올라오는건 짜증이 난다.

이 부분을 소스코드 안쪽에 박아놔가지고 고작 이거하나고치자고 jar새로 만들기도 귀찮고 해서 그냥 쓰긴하는데

이것 말고도 캐싱할 파일이랑 아닌부분이랑 구분도 좀 되면 좋겠고 한데

별로 더 발전시킬 생각은 없는 듯 하다.

너무 복잡해지면 쓰기도 힘들어질테니