Ansible - 여러 서버의 설정을 한번에

Ansible - 여러 서버의 설정을 한번에

들어가며

저희 환경에는 서버가 많습니다. 한두 대가 아니라 100개가 넘는 서버가 존재하고 있습니다. 그리고 그 서버들에는 공통적으로 Nexus가 올라가 있습니다. 외부 라이브러리나 패키지를 받아올 때, 매번 인터넷에서 직접 받는 대신 가까운 Nexus가 한 번 받아 캐싱해두고 빠르게 내려주는 “중간 창고” 역할을 합니다. 외부망이 불안정한 환경에서 이것은 꽤 중요한 장치였습니다.

문제는 이 Nexus마다 proxy 설정을 똑같이 해줘야 하며, 또는 Repository가 추가되거나 여러 설정이 추가되는 경우가 많습니다. 어떤 외부 저장소를 바라볼지, 어떤 저장소를 묶어서 보여줄지를 서버가 수십 대라면 그 설정을 수십 번 반복해야 했습니다. 한 대에 들어가서 설정하고, 빠져나와서 다음 대에 들어가고, 또 똑같이 설정하는 일의 연속이었습니다.

처음 몇 대는 할 만했습니다. 그런데 점차 서버가 늘어나면서 어떤 서버는 설정을 깜빡하고, 어떤 서버는 오타가 나고, 어떤 서버는 저도 모르게 미묘하게 다르게 설정되어 있었습니다. 분명 “모두 똑같이 했다”고 생각했는데, 실제로는 제각각이었습니다.

그러다 문득 이런 생각이 들었습니다. 이 서버들의 설정은 결국 모두 똑같아야 합니다. 그렇다면 “이렇게 설정되어야 한다”는 정답을 한 번만 적어두고, 나머지는 기계가 모든 서버에 똑같이 적용해주면 되지 않을까. 그것이 제가 Ansible을 찾게 된 계기였습니다.

그래서 Ansible이 무엇인가

Ansible은 한마디로 “여러 서버에 같은 작업을 대신 해주는 자동화 도구”입니다. 제가 “이 서버들이 이런 상태가 되어야 한다”고 적어두면, Ansible이 그 서버들에 하나하나 접속해서 그대로 만들어줍니다. 수십 대든 수백 대든, 명령 한 번이면 됩니다.

제가 Ansible에 끌린 데에는 몇 가지 이유가 있었습니다. 알고 보니 이 도구의 성격이 저희 상황과 정말 잘 맞았습니다.

첫째, 서버에 무언가를 미리 설치할 필요가 없었습니다. 자동화 도구 중에는 관리 대상 서버마다 “에이전트”라는 프로그램을 미리 설치해둬야 하는 것들도 있습니다. 그런데 Ansible은 SSH로 접속만 되면 됩니다. 저희처럼 서버가 수십 대 흩어져 있는 상황에서, 그 모든 서버에 또 무언가를 설치하고 관리하는 것은 그 자체로 일이었는데, 그 부담이 없다는 점이 컸습니다.

둘째, 몇 번을 실행해도 안전했습니다. 이 부분이 처음에는 잘 와닿지 않았는데, 써보니 정말 중요한 성질이었습니다. Ansible은 “이미 이렇게 되어 있으면 건드리지 않습니다.” 예를 들어 어떤 설정이 이미 올바르게 되어 있는 서버에 다시 실행해도, 똑같이 또 만드는 것이 아니라 “이미 맞다”고 판단하고 그냥 넘어갑니다. 그래서 “이 서버는 이미 했는지 안 했는지”를 일일이 기억할 필요가 없었습니다. 전체에 한 번 실행하면, 안 된 것만 알아서 채워졌습니다.

셋째, 설정을 글처럼 적을 수 있었습니다. Ansible의 설정 파일은 사람이 읽기 쉬운 형식이라, 프로그래밍을 깊이 몰라도 “무엇을 하려는지”가 눈에 들어왔습니다. 거창한 코드가 아니라, “이 저장소를 이렇게 만들어라”를 차근차근 적어둔 설명서에 가까웠습니다. 나중에 다시 봐도, 동료가 봐도 이해할 수 있다는 점이 좋았습니다.

Ansible의 기본 구조

Ansible이 어떻게 동작하는지 그림으로 보면 한결 이해가 쉽습니다. 전체 구조는 의외로 단순합니다. 가운데에 “자동화 엔진”이 있고, 왼쪽에서 “무엇을 할지”에 대한 정보가 들어오면, 오른쪽의 여러 서버(또는 장비)로 그 작업이 뻗어 나가는 모양입니다.

image1.png

이미지 출처 : https://spacelift.io/blog/ansible-architecture

그림의 각 요소를 하나씩 살펴보면 다음과 같습니다. 어려운 용어처럼 보이지만, 역할을 알고 나면 단순합니다.

자동화 엔진 (Automation Engine): 그림 한가운데에 있는 핵심입니다. 시킨 일을 실제로 처리하는 “두뇌” 역할로, 보통 작업용 PC나 별도의 관리 서버 한 곳에 둡니다. 이를 제어 노드(Control Node)라고 부르며, 여기에서 모든 것이 시작됩니다.

Playbook (플레이북): “무엇을 어떻게 할지”를 적어둔 작업 지시서입니다. 사람이 읽기 쉬운 형식(YAML)으로 “이 저장소를 이렇게 만들어라” 같은 작업을 차근차근 적어둡니다. 정답을 한 번 적어두는 곳이 바로 여기입니다.

Inventory (인벤토리): “어떤 서버들에 적용할지” 목록입니다. 저희로 치면 수십 대 Nexus 서버의 주소록인 셈입니다. 새 서버가 생기면 여기에 한 줄 추가하면 됩니다. 저 같은 경우는 작업이 완료되는 경우 서버의 주소를 자동으로 주석하여, 반복 실행을 방지하면서 작업을 하였습니다.

Modules (모듈): 실제 작업을 수행하는 작은 도구들입니다. “파일을 복사하라”, “설정을 바꿔라” 같은 일을 하는 부품으로, Ansible이 필요할 때 대상 서버에 잠깐 보내서 실행시키고 끝나면 정리합니다.

Plugins (플러그인) / API: Ansible의 기능을 확장하거나 다른 시스템과 연결할 때 쓰는 부분입니다. 처음에는 깊이 몰라도 무방하며, “이런 것으로 확장할 수 있다” 정도만 알아두면 충분합니다.

Hosts / Networking (대상): 그림 오른쪽의, 실제로 작업이 적용되는 서버나 네트워크 장비들입니다. 저희 경우에는 Nexus가 올라간 수십 대의 서버가 여기에 해당합니다. 핵심은, 이 대상들에는 아무것도 미리 설치할 필요가 없다는 점입니다.

이 그림에서 가장 주목할 부분은 흐름의 방향입니다. 왼쪽(작성한 지시서)에서 → 가운데(엔진)를 거쳐 → 오른쪽(수십 대 서버)으로 작업이 한 번에 뻗어 나갑니다. 제가 할 일은 왼쪽에 “정답”을 적는 것까지이고, 그 정답을 모든 서버에 똑같이 나르는 일은 엔진이 알아서 처리합니다. 손으로 한 대씩 들어가던 그 반복이, 이 한 장의 그림으로 정리된 것입니다.

무엇이 달라졌나

자동화를 적용하고 나서 가장 먼저 체감한 것은 시간이었습니다. 예전에는 서버 수십 대를 돌며 하루를 꼬박 쓰던 일이, 이제는 명령 한 번으로 끝났습니다. 새 서버가 추가되어도, 목록에 한 줄 더하고 다시 실행하기만 하면 되었습니다.

하지만 더 본질적인 변화는 “일관성”이었습니다. 이제 모든 서버가 똑같이 설정된다는 것을 믿을 수 있게 되었습니다. 사람이 손으로 할 때 생기던 미묘한 차이들이 사라졌습니다.

그리고 마음이 한결 편해졌습니다. 예전에는 “혹시 빠진 서버가 없을까” 하는 막연한 불안이 늘 있었는데, 이제는 전체에 한 번 실행하면 되었습니다. 이미 맞는 서버는 그대로 두고, 어긋난 서버만 알아서 맞춰지기 때문입니다. 이 “안 된 것만 채워준다”는 안정감이, 수십 대를 책임지는 부담을 크게 덜어주었습니다.

물론 자동화가 만능은 아니었습니다. 오히려 “한 번에 모두에게 적용된다”는 그 강력함이, 그대로 위험이 되기도 했습니다.

손으로 할 때는 한 대에서 실수하면 그 한 대만 문제였습니다. 그런데 자동화는 다릅니다. 정답을 잘못 적으면, 그 잘못된 설정이 “모든” 서버에 똑같이, 순식간에 퍼집니다. 한 곳의 실수가 수십 대의 사고가 되는 것입니다. 그래서 전체에 적용하기 전에는, 먼저 한두 대에만 시험해보는 습관이 반드시 필요했습니다.

그리고 모든 작업은 최대한 보수적으로 제한하여 설정하는 것이 좋습니다. 결국 자신 파악하지 못한 문제가 발생하면 전체의 문제가 될 수 있기 때문입니다.

보안 측면에서도 배운 점이 있습니다. 이 도구는 결국 여러 서버에 “접속”해서 작업합니다. 그 말은, 접속에 필요한 계정 정보나 Nexus 관리자 비밀번호 같은 민감한 값들이 어딘가에 적혀야 한다는 뜻입니다. 처음에는 편하게 설정 파일에 그대로 적어두고 싶은 유혹이 있었습니다. 하지만 그것은 그 파일을 보는 누구에게나 비밀번호를 통째로 넘겨주는 것과 같았습니다.

다행히 이런 도구들은 민감한 값을 따로 암호화해서 보관하는 방법을 갖추고 있었습니다. 비밀번호는 설정 본문과 분리해서 잠가두고, 저장소에 올라가지 않도록 했습니다. “편하게 적어두고 싶다”는 마음을 한 번 참는 것이, 나중의 큰 사고를 막는 길이었습니다. 자동화를 한다는 것은, 그만큼 민감한 정보를 한곳에서 다루게 된다는 뜻이기도 했습니다.

마치며

돌아보면, 제가 Ansible을 도입한 것은 기술적 배움 때문이 아니었습니다. 그저 “같은 일을 수십 번 반복하기 번거로워서”, 그리고 “사람 손으로는 자꾸 틀려서”였습니다.

그런데 그 과정에서 예상치 못한 것을 얻었습니다. 단순히 시간을 아낀 것이 아니라, 일하는 방식이 바뀌었습니다. “절차를 기억하는 사람”에서 “원하는 상태를 적어두는 사람”으로 말입니다. 머릿속에만 있던 노하우가, 누구나 읽고 고칠 수 있는 글이 되었습니다. 그리고 “우리 서버들이 모두 똑같다”는 것을, 막연한 기대가 아니라 사실로 확인할 수 있게 되었습니다.

혹시 수십 대의 서버 앞에서 비슷한 고민을 하고 계신 분이 있다면, 한 번쯤 생각해보시길 권합니다. 그 반복을 꼭 손으로 해야 할까요. “정답을 한 번 적고, 나머지는 기계에 맡긴다”는 발상은, 생각보다 많은 것을 바꿔놓습니다. 적어도 저에게는 그랬습니다. 부족한 글 읽어주셔서 감사합니다.

Bang

Site footer