Part 1에서 다 하지 못한, 보충할 내용이 있어 추가합니다.
Immutable Infrastructure 도 언급할 필요가 있을 것 같아서요.
Chad Fowler가 2013년 자신의 블로그 글 “Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components,” 에서 처음으로 “immutable infrastructure”라는 단어를 사용했습니다. 그러나 다른 사람도 비슷한 아이디어를 이야기한 적이 있습니다. Martin Fowler는 2012년에 phoenix server 라는 표현을 썼습니다.
(Snowflake server vs Phoenix server 또는 pet vs cattle 에 대해 찾아보면 이와 비슷한 이야기입니다.)
Immutable Infrastructure란,
과거에는 서버 설정이 지속적으로 변경될 수 있었다면,
서버를 수정하지 말고 (이미지화) 활용하다가 변경이 필요하면 다시 만들어서
(테스트 후에) 바꿔서 쓰고 오래된 것은 폐기하자는 것이다.
간단히 말해, 수정(change)하지 말고 대체(replace)하자는 것이다.
클라우드를 활용한다고 가정하면 이해가 쉬울 것이다.
II의 장점은 다음과 같다.
- 일관성 : 수많은 서버를 손으로 설정하지 않고 이미지를 배포하는 방식이므로
- 안정성 : 실수나 오류가 생길 가능성이 낮거나 없다
- 문제해결/복구 : 쉽다
- 높은 확장성
II를 구현한 것이 Docker라고 할 수 있다.
서버(개발환경) 과 data를 분리하고
서버를 이미지화하여 사용하자
이 때 코드(Dockerfile)로 서버의 설정을 정의하고 버전관리하자.
이를 통해 개발환경의 자동화를 달성할 수 있다.