원본 게시물입니다~
고객에게 서비스를 제공하기 위해서는 서버가 필요하다.
어떻게 하면 서버를 더 효율적이고, 편리하게, 안전하게 관리할 수 있을까?
그리고 위와 같은 관점에서 도커는 왜 나오게 되었을까?
옛날 옛적엔 제공하는 서비스가 늘어나거나 사용량이 늘어 증설이 필요할 땐 서버를 한대 더 구매했다.
이렇게 서버의 구매, 설치, 운영을 기업이 직접하는 방식을 On-premise라 한다.
옛날 옛적의 On-premise 방식은 다음의 문제가 있었다.
정확히 동일한 서비스를 제공하기 위해 정확히 동일한 서버 설정을 해야하는데 여기에도 많은 자원이 들어가게 된다. 각 Directory의 용량 설정부터 종속성 관리, 방화벽 설정 등을 동일하게 해주어야 하는데 명령어를 통해 관리하다 보니 언제, 누가, 어떻게 했는지 관리하는 것이 굉장히 어렵고 복잡했다.
구매 보고서 작성 -> 보고서 승인 -> 서버 구매 → 서버 설치 → 하드웨어 조립 → 네트워크 연결 → OS 설치 → 방화벽 설정 등등 거쳐야 하는 과정이 너무 많다. 때문에 필요한 시점에 인프라를 바로 투입할 수 없게 되고 대응이 늦어져 회사에 경제적 손실이 생기기 시작한다.
1번*을 해결하기 위해 등장한 것이 설정 관리 도구다.
대표적으로 ANSIBLE(앤서블)이 있다.
수많은 서버들에 동시에, 동일한 환경을 배포하는 것이 현실적으로 많은 제약이 있었다.
이를 위한 고안된 것이 (Infrastructure as a Code)라는 개념이며, 이는 환경의 배포와 구성을 규격화된 코드로 정의해 사용하는 것을 의미한다.