Ansible을 이용하여 Linux 업데이트 자동화 (7편) - 기존 구성 파일과 새로운 구성 파일 비교

Ansible을 이용하여 Linux 업데이트 자동화 (6편) - 패키지 변경 로그 기록에서 이어지는 글이다.

6편에서는 실제 업데이트 후 어떤 패키지가 업그레이드, 설치, 제거되었는지 로그로 남기는 방법을 다루었다.
다만 실제 운영에서는 패키지 변경 내역을 확인하는 것만으로 끝나지 않는다.
특히 Nginx, Apache, PHP, MariaDB처럼 설정 파일을 직접 튜닝해 사용하는 서비스는, 패키지 관리자가 함께 배포한 새 설정 파일과 기존 운영 설정을 비교하는 과정이 꼭 필요하다.

7편에서는 Debian/Ubuntu와 RHEL 계열에서 기존 구성 파일과 새로운 구성 파일을 비교하는 방법을 다룬다.

1) 왜 패키지 업데이트 후 설정 파일 비교가 필요한가?

Debian/Ubuntu 계열에서 *.conf 등의 구성 파일을 사용자가 수정했고, 패키지 관리자가 새 버전의 설정 파일을 함께 배포하면 dpkg가 "기존 로컬 버전을 유지할지, 패키지 관리자의 새 버전으로 바꿀지" 묻는 화면을 띄운다. 5편에서는 dpkg_options: "force-confold"를 사용하여 기존 로컬 설정 파일을 유지하도록 했다.

RHEL 계열은 Debian의 dpkg conffile prompt처럼 업그레이드 도중에 바로 물어보는 방식이 아니라, 보통 비대화형(non-interactive)으로 처리한다.
패키지 관리가 rpm 기반이라서, 설정 파일 충돌이 나도 화면에서 로컬 버전 유지할지, 패키지 배포자 버전으로 바꿀지를 즉석에서 묻지 않는다.

대신 패키지 spec에서 설정 파일이 어떻게 선언되어 있느냐에 따라 이런 식으로 처리된다.
• 기존 로컬 파일을 유지하고, 새 파일을 *.rpmnew로 둔다.
• 새 파일로 교체하고, 예전 파일을 *.rpmsave로 둔다.

실제 운영 환경에서는 패키지가 바뀌었으면 기존 구성 파일과 새 구성 파일의 차이점을 비교하여, 새롭게 추가된 기능, 보안 옵션이 있으면 기존 구성에 추가해야 안정적인 운영이 가능하다.

2) Debian/Ubuntu 계열에서 기존 구성 파일과 새 구성 파일 비교하기

Debian/Ubuntu 계열에서는 패키지 업데이트 후 현재 사용 중인 설정 파일과, 패키지 관리자가 새로 배포한 설정 파일 후보를 비교하는 것이 핵심이다.

dpkg는 설정 파일 충돌이 발생했을 때 현재 사용 중인 로컬 설정을 유지하거나, 새 패키지 버전을 적용하면서 이전 파일을 별도로 남길 수 있다. 이때 기존 파일이나 새 파일이 .dpkg-old, .dpkg-dist 같은 형태로 남을 수 있다. 따라서 Debian/Ubuntu 계열에서는 단순히 업데이트가 끝났는지만 볼 것이 아니라, 현재 설정 파일과 같은 경로에 새로 생긴 .dpkg-dist 또는 .dpkg-old 파일이 있는지 먼저 확인하는 편이 좋다.

운영 관점에서는 /etc 아래의 모든 파일을 무작정 비교하기보다, 실제로 수정 이력이 있는 파일부터 우선적으로 보는 것이 효율적이다. 예를 들어 Apache 관련 설정 파일, php.ini, MariaDB 설정 파일처럼 서비스 동작에 직접 영향을 주는 파일이 우선 대상이 된다.

실제 확인은 아래처럼 하면 된다.

# 새로 남겨진 설정 파일 후보 찾기
find /etc -type f \( -name "*.dpkg-dist" -o -name "*.dpkg-old" \)

# 현재 설정 파일과 새 파일 비교
diff -u 기존설정파일 새설정파일
(e.g. diff -u /etc/mysql/mariadb.conf.d/50-server.cnf /etc/mysql/mariadb.conf.d/50-server.cnf.dpkg-dist)

vimdiff 기존설정파일 새설정파일
(e.g. vimdiff /etc/mysql/mariadb.conf.d/50-server.cnf /etc/mysql/mariadb.conf.d/50-server.cnf.dpkg-dist)

중요한 점은 무조건 새 파일을 덮어쓰거나, 반대로 무조건 기존 파일만 고집하는 것이 아니라, 실제 차이를 먼저 확인한 뒤 필요한 설정만 반영하는 것이다.

3) RHEL 계열에서 기존 구성 파일과 새 구성 파일 비교하기

RHEL 계열도 운영 흐름은 Debian/Ubuntu 계열과 크게 다르지 않다. 패키지 업데이트가 끝난 뒤에는 현재 사용 중인 설정 파일과, 업데이트 과정에서 별도로 남겨진 새 설정 파일 또는 기존 설정 파일 백업을 비교하는 과정이 필요하다.

RHEL 계열에서는 패키지 업데이트 후 .rpmnew, .rpmsave 같은 파일이 생성되는 경우가 있다. 따라서 운영 환경에서는 현재 서비스가 실제로 읽고 있는 설정 파일만 볼 것이 아니라, 같은 경로 또는 관련 디렉터리에 새로 생긴 .rpmnew, .rpmsave 파일이 있는지도 함께 확인하는 편이 좋다. Debian/Ubuntu 계열이 .dpkg-dist, .dpkg-old를 확인하는 흐름이라면, RHEL 계열은 .rpmnew, .rpmsave를 중심으로 본다고 이해하면 된다.

Apache 관련 설정 파일, PHP 설정 파일, MariaDB 설정 파일처럼 직접 튜닝 이력이 있는 파일부터 우선적으로 비교하는 것이 좋다. 결국 중요한 것은 파일 이름 자체보다, 현재 운영 중인 설정과 패키지 업데이트 후 새로 제공된 설정 후보가 어떻게 다른지를 확인하는 것이다.

실제 확인은 아래처럼 하면 된다.

# 새로 남겨진 설정 파일 후보 찾기
find /etc -type f \( -name "*.rpmnew" -o -name "*.rpmsave" \)

• *.rpmnew : 기존 로컬 파일을 유지하고, 새 파일을 *rpmnew로 둔 상태
• *.rpmsave : 새 파일로 교체하고, 예전 파일을 *.rpmsave로 둔 상태

# 현재 설정 파일과 새 파일 비교
diff -u 기존설정파일 새설정파일
vimdiff 기존설정파일 새설정파일

여기서도 핵심은 무조건 새 파일로 덮어쓰거나, 반대로 기존 파일만 고집하는 것이 아니다. 먼저 차이를 확인하고, 보안, 성능, 호환성 측면에서 새 버전에서 반영할 부분과 기존 튜닝을 유지할 부분을 구분해서 적용하는 편이 운영상 더 안전하다. 즉, RHEL 계열에서 비교해야 할 파일은 현재 서비스가 실제로 사용하는 설정 파일과 패키지 업데이트 후 별도로 남겨진 .rpmnew 또는 .rpmsave 파일이다.

4) 어떤 설정을 반영하고 어떤 설정은 유지할 것인가?

기존 구성 파일과 새 구성 파일의 차이를 확인했다면, 그다음에는 어떤 설정을 반영하고 어떤 설정은 유지할지 판단해야 한다. 이때 중요한 점은 단순히 "새 파일이 있으니 새 설정을 전부 반영한다"라거나, "반대로 기존 파일을 계속 유지한다"처럼 한쪽으로만 결정하지 않는 것이다.

운영 환경에서는 현재 서비스가 정상적으로 동작하도록 만들기 위해 직접 조정한 값이 많다. 예를 들어 메모리 사용량, timeout, 업로드 크기 제한, 로그 관련 설정, 데이터베이스 버퍼나 연결 수처럼 운영 환경에 맞게 조정한 값은 기존 값을 유지해야 하는 경우가 많다. 반면 패키지 관리자가 새 버전에서 추가한 보안 관련 기본값, deprecated된 옵션 교체, 문법 변경, 성능 관련 권장 설정은 새 구성 파일 쪽을 참고해 반영할 필요가 있다.

즉, 비교할 때는 아래 기준으로 나눠서 보는 것이 좋다.

1. 운영 환경에 맞게 직접 튜닝한 값인가?
2. 새 버전에서 추가된 보안 또는 호환성 관련 설정인가?
3. 기존 옵션이 더 이상 권장되지 않거나 deprecated된 것은 아닌가?
4. 현재 서비스에 꼭 필요한 설정인가, 아니면 예전 환경의 흔적에 가까운가?

예를 들어 Apache 관련 설정에서는 기존 가상 호스트 구조나 모듈 활성화 방식은 유지하되, 새 버전에서 추가된 보안 헤더 관련 예시나 기본 정책은 검토할 수 있다. PHP 설정에서는 메모리 제한, 업로드 크기, 실행 시간처럼 운영 환경에 맞춘 값은 유지하되, 새 버전에서 추가된 기본 권장값이나 deprecated된 옵션은 확인해 보는 것이 좋다. MariaDB 설정에서도 버퍼 크기, 연결 수, 문자셋, 로그 정책처럼 직접 튜닝한 값은 쉽게 덮어쓰지 말고, 새 버전의 샘플 설정에서 달라진 부분이 있다면 이유를 확인한 뒤 선택적으로 반영하는 편이 안전하다.

결국 가장 좋은 방식은 "현재 운영에 필요한 값은 유지하고, 새 버전이 요구하는 보안, 호환성, 문법 변경은 선택적으로 반영한다"는 원칙으로 보는 것이다. 즉, 설정 파일 비교의 목적은 새 파일을 그대로 덮어쓰는 것이 아니라, 새 버전에서 달라진 점을 확인한 뒤 현재 운영 환경에 맞게 필요한 부분만 반영하는 데 있다.

5) 비교 후 서비스 반영과 검증

기존 구성 파일과 새 구성 파일의 차이를 확인하고, 필요한 설정만 선택적으로 반영했다면 그다음에는 실제 서비스에 반영하고 검증하는 과정이 필요하다. 여기서 중요한 점은 파일만 수정하고 끝내는 것이 아니라, 서비스가 정상적으로 다시 동작하는지까지 확인하는 것이다.

설정 반영 후에는 먼저 해당 서비스의 설정 문법이나 구성이 유효한지 점검하는 편이 좋다. 서비스에 따라 별도의 설정 테스트 명령을 제공하는 경우가 있으므로, 가능하다면 reload나 restart 전에 먼저 확인하는 것이 안전하다. 그다음 실제로 서비스를 reload 또는 restart하고, 서비스 상태와 로그를 함께 확인하면 된다.

운영 흐름은 보통 아래 순서로 정리할 수 있다.

1. 기존 설정 파일에 필요한 항목만 반영한다.
2. 가능하면 서비스별 설정 테스트 명령으로 문법이나 구성을 먼저 확인한다.
3. 문제가 없으면 서비스를 reload 또는 restart한다.
4. systemctl status로 서비스 상태를 확인한다.
5. journalctl이나 서비스 로그를 확인해 오류가 없는지 본다.
6. 실제 애플리케이션이나 웹 서비스, DB 접속이 정상인지 추가로 확인한다.

예를 들면 아래와 같은 형태로 점검할 수 있다.

# 서비스 상태 확인
systemctl status 서비스이름

# 서비스 로그 확인
journalctl -u 서비스이름 -n 50 --no-pager

# 필요 시 reload 또는 restart
systemctl reload 서비스이름
systemctl restart 서비스이름

여기서도 핵심은 설정 파일을 반영하는 것 자체보다, 반영 이후 서비스가 실제로 정상 동작하는지 확인하는 것이다. 예를 들어 Nginx, Apache, PHP, MariaDB처럼 운영 환경에서 직접 튜닝한 설정이 있는 서비스는, 설정 파일 diff만 보고 끝내지 말고 서비스 상태와 실제 동작 결과까지 함께 확인하는 편이 안전하다.

즉, 설정 파일 비교의 마지막 단계는 단순한 파일 수정이 아니라, 반영 > restart 또는 reload > 상태 확인 > 로그 확인 > 실제 동작 확인까지 이어지는 검증 과정이라고 이해하면 된다.

6) 최종 Ansible 코드 파일 링크

https://drive.google.com/file/d/1ya0DStAjEbjXf8EpCLZze8YhqhSR4swC/view?usp=sharing

7편의 최종 Ansible 코드이다. 위 링크의 압축 파일에는 ansible.cfg, update_all.yml 등 모든 Ansible 코드가 포함되어 있다.

7) 마무리하며

Ansible을 이용하여 Linux 업데이트 자동화 (1편)부터 이어져온 글이 7편에서 마무리됐다.
(만약 추가 개선할 부분이 있거나, 신기능이 추가되면, 다음 8편에서 다룰 예정이다.)

많은 서버를 관리하기 위해 SSH로 일일이 접속한 뒤 업데이트해야 해서 벅찬 상황이라면, 이번 기회에 Ansible을 도입하여 업데이트를 자동화해볼 것을 적극 권장한다.

업데이트를 자동화하여 남는 시간에 커피 한잔의 여유, 짧은 휴식을 가지길 바란다.