최근 AWS에서 Bitnami WordPress 지원 종료 안내를 받았습니다. 결론은 업데이트를 종료하기 때문에 보안과 유지보수에 문제가 생길수 있으므로 새로운 환경으로 이전하라는 안내였습니다.
Bitnami WordPress는 설치가 간편하고 초기 구축 속도가 빠르다는 장점이 있었습니다. 하지만 AWS의 지원 종료로 인해 앞으로 보안 업데이트를 기대하기 어려워졌고, 일반적인 Apache + PHP + MySQL 환경과 다른 디렉터리 구조 때문에 유지보수 시 불편함도 존재헀습니다. 따라서 이번 기회에 표준적인 워드프레스 환경으로 이전하기로 결정했습니다.
아마존에서는 친절하게도 마이그레이션에대한 가이드를 제공해줬습니다.
aws 마이그레이션 가이드 – https://docs.aws.amazon.com/lightsail/latest/userguide/migrate-from-bitnami-to-lightsail-blueprints.html
이전에 유료 마이그레이션 플러그인을 사용했음에도 각종 오류와 설정 충돌이 발생했는데, 이번에는 오히려 무료 플러그인을 사용한 방식을 쓰면서도 안정적으로 이전이 가능했습니다.
이 글에서는 aws에서 제공하는 가이드 보다 더 자세하게 실제 이전 과정과 발생했던 문제 및 해결 방법을 기록합니다.
기존 사이트 전체 백업
가장 먼저 해야 할 작업은 기존 사이트를 하나의 파일로 백업하는 것입니다.
All-in-One WP Migration and Backup 플러그인 설치하고 활성화
플러그인 메뉴 – 내보내기
고급 설정 – 내보낼 파일 안에 포함할 정보들
- 데이터베이스
- 업로드 이미지
- 테마
- 플러그인
- 워드프레스 설정
등의 내용들을 선택 가능하고 제외 하지 않으면 현재 홈페이지의 모든 정보를 담은 파일로 만들 수 있습니다.
내보내기 사이트 대상을 클릭해 파일을 누르면 .wordpress 파일로 압축이되고 다운로드 가능합니다.
압축이 완료되면 다운로드 버튼이 나옵니다. 다운로드 받은 파일은 즉, 사이트 전체를 통째로 압축한 형태의 파일이라 생각하면 됩니다.
새 환경의 워드프레스 서버 생성
리눅스 환경 – 워드프레스 선택
인스턴스 생성 시 주의할 점
WordPress details를 보면 lightsail과 originally packaged by Bitnami 두 가지 중 선택을 해야 합니다.
아직은 빗나미 이미지를 선택 가능하지만 앞으로 지원이 종료될 예정이고 또 지금 이것 때문에 서버를 새로 만드는 것기 때문에 밑에 것을 선택하지 말고 위에 것으로 선택해야 합니다.
이렇게 생성하면 Apache + PHP + MySQL 구조의 표준적인 환경을 사용할 수 있습니다.
초기 관리자 계정 확인하기
인스턴스 생성이 완료되면 ssh로 접속합니다.
#application_credentials 파일 내용 읽기
cat application_credentials초기 관리자 계정은 application_credentials 파일에 저장되어 있습니다. 경로는 기본 경로이며 절대 경로로는 /home/admin/ 경로안에 있습니다. 이정보는 초기 설치 직후 워드프레스 관리자 로그인이 가능합니다.
정확히 말하면 이 정보는 데이터베이스 접속 정보이며, DB_USER, DB_PASSWORD를 뜻합니다.
사이트 복원 후에는 워드프레스 관리자 계정이 기존 사이트의 계정으로 변경됩니다.
워드프레스 백업 파일 업로드
워드프레스에 관리자로 로그인하면 All-in-One WP Migration and Backup이 처음부터 설치되어서 활성화만 하면 사용 가능합니다. 없다면 설치해주고 활성화 합니다.
업로드 용량 제한 해제
백업한 파일이 433MB였는데 업로드를 시도하니 업로드 용량 제한(80MB)에 걸려서 업로드가 안됩니다.
php 기본 업로드 제한 기준을 변경하기 위해 php.ini 파일을 수정해야 합니다.
sudo vi /etc/php/8.2/apache2/php.ini
upload_max_filesize = 80M
post_max_size = 80M
써진 부분 각각 찾고 여유 있게 늘려줍니다.
vi에서 검색 방법: 커서가 하단에 있을때(esc를 한번 누르면 커서가 하단으로 내려감) /검색내용 엔터
예시)
upload_max_filesize = 500M
post_max_size = 500M
#apache 재시작
sudo systemctl restart apache2 다시 업로드 창에서 새로고침 후 업로드
워드프레스 복원 중 경고 창
기존 서버 8.3 새 서버 8.2 버전 이 정도 차이라면 대부분 문제 없이 진행됩니다.
제 경우에는 PHP 8.4 환경에서 사용하던 사이트를 PHP 8.2 환경으로 복원했음에도 특별한 문제가 발생하지는 않았습니다. 우선 proceed를 클릭해줍니다.
※ 보통은 8.1에서 8.2로 버전을 올리는 경우는 문제가 생길 가능성이 낮지만 버전을 낮추거나. 7.x에서 8.x로 앞자리가 바뀌는 경우는 문제가 생길 가능성이 높습니다. 테마나 플러그인 때문에도 문제가 생길 수 있습니다. 바로 밑에서 이런 오류에 대한 대처 방법을 정리합니다. 가장 안전한 방법은 이전에 쓰던 php 버전을 그대로 사용하것이 될수도 있습니다.
PHP버전 문제 해결 방법 정리
플러그인 때문에 문제가 생긴다면 SSH로 접속해 전부 비활성화해서 문제를 만든 플러그인을 찾아야합니다.
500 에러가 발생한다면 에러로그를 확인해봐야 합니다.
SSH로 접속해 동일한 PHP버전을 설치해 해결하는 방법도 있습니다
플러그인 때문에 500 에러가 생기는 케이스 ( 플러그인 비활성화 )
##모든 플러그인 디렉터리를 변경해서 비활성화하는 방법- 플러그인 디렉터리 이름을 바꿔서 전부 비활성화
cd /var/www/html/wp-content
mv plugins plugins_backup
mkdir plugins
## 플러그인 목록 확인 ##
#설치된 플러그인과 그 상태(Active/Inactive)확인
wp plugin list --path=/var/www/html
#모든 플러그인 비활성화
wp plugin deactivate --all --path=/var/www/html
# 특정 플러그인 비활성화
wp plugin deactivate 플러그인_디렉터리이름 --path=/var/www/html
# 특정 플러그인 활성화
wp plugin activate 플러그인_디렉터리이름 --path=/var/www/html
에러 로그 확인하기
#아파치 에러로그
sudo tail -f /var/log/apache2/error.log위의 명령어를 치고 새로고침 했을 때 올라오는 로그를 확인하기
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );wp-config.php 파일에 위에 내용을 추가하고 워드프레스 내부 로그 확인하기
확인은 /var/www/html/wp-content/debug.log 이 파일에서
php 버전 맞추기 (호환성 문제 해결)
##새로운 PHP 8.4 저장소 추가 및 설치##
# PHP 8.4 저장소 추가 및 업데이트
sudo add-apt-repository ppa:ondrej/php -y
sudo apt update
# PHP 8.4 및 필수 확장 모듈 설치
sudo apt install php8.4 php8.4-mysql php8.4-xml php8.4-mbstring php8.4-gd -y
##아파치 모듈 연결 전환##
# 기존 8.2 연결 해제 및 8.4 연결
sudo a2dismod php8.2
sudo a2enmod php8.4
# 아파치 서버 재시작
sudo systemctl restart apache2
##구버전(8.2) 삭제 및 정리##
# 8.2 관련 패키지 삭제
sudo apt purge php8.2* -y
sudo apt autoremove -y
##최종 버전 확인##
php -v고유주소(Permalink) 재생성
완료되면 finish클릭, 이제 관리자 로그인을 다시 해야됩니다. 업로드를 했으므로 로그인 정보가 바뀐 상태입니다. 백업파일을 만들었던 원래의 사이트 로그인 정보로 로그인합니다.
이렇게 완료가 되어도 몇 가지 문제가 남아 있습니다.
이미지가 안보임, 게시물 클릭시 404 오류, 내부 링크 오류 가 무조건 나타납니다.
이유는 이전 서버의 Rewrite 규칙을 그대로 기억하고 있기 때문에 고유주소 갱신을 해줘야합니다.
설정 – 고유주소 – 변경 사항 저장 (아무것도 건드리지 말고) 버튼 클릭
이 작업만으로 Rewrite 규칙이 새 환경을 기준으로 다시 생성됩니다.
이제 모든 이미지와 내용 그리고 링크들에 문제가 없는 것을 확인합니다.
DNS를 새 서버로 변경
사이트와 데이터는 모두 복원되었습니다. 남은 작업은 도메인을 새 서버로 연결하는 것입니다.
같은 계정의 aws를 쓰고 있고 기존에 스태틱ip를 연결해 뒀다면
스태틱 ip를 기존의 인스턴스에서 Detach하고 새 인스턴스에 attach만 하면 됩니다.
스태틱 ip를 연결하지 않은 경우라면 새 인스턴스에서 새롭게 만들어진 ip를 도메인 DNS에 입력해줍니다.
옮기면 몇 분 정도 기다렸다가 도메인으로 접속해봅니다.
SSL 인증서 설치
도메인으로 접속했을때 ssl을 설치하지 않았으니 안전하지 않은 사이트로 나올것입니다. 이 때 인증서를 설치해야 합니다. 그 전에는 DNS 변경이 제대로 이루어지지 않아 인증서 발급이 안될테니 이 때를 기다렸다 SSL 설치를 진행합니다.
sudo apt update
#Certbot 설치
sudo apt install certbot python3-certbot-apache -y
#SSL 인증서 발급 및 아파치 자동 설정 등록
sudo certbot --apache -d 본인도메인.com -d www.본인도메인.com※ “sudo certbot –apache -d 본인도메인.com -d www.본인도메인.com” 이 명령어는 sudo /opt/bitnami/bncert-tool 이 명령어 못지 않게 아니 오히려 더 좋습니다. default-ssl.conf 등을 분석해서 인증서 경로를 찾아내고, 필요한 설정 줄을 알아서 삽입하거나 수정, HTTP를 HTTPS로 보내는 규칙” 같은 것들도 명령 한 번으로 아파치 설정 파일에 깔끔하게 작성, 아파치뿐만 아니라 Nginx, HAProxy 등 어떤 환경으로 나중에 서버를 옮기더라도 Certbot 사용법만 알면 똑같이 활용가능, Certbot은 아파치 설정 파일에 무엇을 추가했는지 로그로 다 보여줌, /etc/cron.d/certbot 등에 갱신 스케줄을 자동으로 등록해 줌 등…
발급을 진행하면
이런 질문이 나오고 일단 2번을 누르면 되는데
2번을 눌렀을 때 아파치 설정 파일 안에 도메인 주소(ServerName)가 명확히 지정되어 있지 않아서 충돌
apache 설정
sudo vi /etc/apache2/sites-available/000-default.conf DocumentRoot /var/www/html
# === [아래 내용 추가] ===
ServerName 도메인.com
ServerAlias www.도메인.com
<Directory /var/www/html>
AllowOverride All
</Directory>sudo vi /etc/apache2/sites-available/default-ssl.conf DocumentRoot /var/www/html
# === [아래 내용 추가] ===
ServerName 도메인.com
ServerAlias www.도메인.com
<Directory /var/www/html>
AllowOverride All
</Directory>
추가 후 저장
# 아파치 문법 검사 (Syntax OK 꼭 확인)
sudo apache2ctl configtest
#아파치 재시작
sudo systemctl restart apache2아파치 재시작이 됐으면 SSL 설치 마무리 준비가 끝났습니다.
#수정한 아파치 설정에 install만 다시 요청
sudo certbot install --cert-name 도메인.comwp-config.php 파일 설정
복원 후 사이트가 정상 동작하더라도 wp-config.php 파일을 꼭 확인하는 것이 좋습니다.
먼저 /var/www/html 디렉터리 내를 확인합니다.
그런데 예상과는 달리 wp-config.php파일은 없고 wp-config-sample.php 파일만 존재했습니다.
이상한 점은 wp-config.php 파일이 없음에도 워드프레스가 동작을 하고 있다는 것입니다.
그래서 아래 명령어로 서버 전체에서 wp-config.php 파일 위치를 확인해 보았습니다.
find / -name wp-config.php 2>/dev/null확인 결과 /var/www/wp-config.php 파일이 상위 디렉터리에 존재했습니다.
워드프레스는 기본적으로 /var/www/html/wp-config.php 파일을 먼저 확인하며, 해당 파일이 없을 경우 상위 디렉터리인 /var/www/wp-config.php 파일도 사용할 수 있습니다.
실제 /var/www/wp-config.php 파일의 내용을 확인해 보니 기존 사이트의 설정 파일이 아니라 AWS WordPress이미지가 기본 제공하는 파일로 보였습니다.
따라서 반드시 wp-config.php를 생성해야 하는 것은 아닙니다. 기존 /var/www/wp-config.php를 수정해서 사용해도 됩니다.
다만 현재 읽기 전용 권한으로 생성되어 있어 있기 때문에 sudo chmod u+w /var/www/wp-config.php 명령어로 권한을 바꾼 후 사용해야 합니다.
다만 저는 사이트 주소, 데이터베이스 정보 등을 직접 정리하면서 관리하기 위해 wp-config-sample.php 파일을 이용해 /var/www/html/wp-config.php 파일을 새로 생성해 사용했습니다.
# wp-config-sample.php 파일을 wp-config.php파일로 복사
sudo cp /var/www/html/wp-config-sample.php /var/www/html/wp-config.php
# wp-config.php 파일 vi로 열기
sudo vi /var/www/html/wp-config.php열어서 파일 내용을 확인합니다.
사이트 주소 지정
# 사이트를 지정해 워드프레스가 항상 올바른 도메인을 기준으로 동작하게 설정
define('WP_SITEURL', 'https://도메인.com');
define('WP_HOME', 'https://도메인.com');이렇게 https://도메인.com 혹은 https://www.도메인.com만을 지정해놔도
자동으로 리다이렉트 됩니다.
예) non-www 도메인을 위에 써놓은 경우
www 도메인 접속 -> non-www 도메인 사이트로 리다이렉트
보안키 입력
보안키 받는 사이트 https://api.wordpress.org/secret-key/1.1/salt
여기에 들어가면 새로고침을 할때마다 다른 보안키를 얻습니다. 새로고침 할 필요는 없고 들어가서 나오는 값들을 put your unique phrase here 8곳 모두 지우고 그 안에 각 값을 이름에 맞게 붙여 넣습니다.
꼭 ‘따옴표 기준으로 전부 다 넣어야합니다.
데이터베이스 기본 정보 입력
우선 DB_NAME, DB_USER, DB_PASSWORD 값을 각각 넣어야 합니다. /home/admin/application_credentials 파일에 써져 있던 정보 두가지는 DB_USER와 DB_PASSWORD입니다. 그리고 기본 DB_NAME은 wordpress-db 입니다. 이 정보들을 wp-config.php 안의 database_name_here, username_here, password_here 여기에 각각 넣어주면됩니다.
아래의 데이터 베이스 확인과 관련된 내용은 정확히 맞는지 확인해보기 위함이며 굳이 할 필요는 없습니다.
#데이터베이스 접속
sudo mysql -u rootSHOW DATABASES; -- 현재 데이터베이스 목록을 보여줍니다.
--데이터 베이스 리스트에 wordpress-db라는 것이 보임. 이것이 DB_NAME
--사용자 확인
SELECT user, host FROM mysql.user;
--비밀번호 검증 굳이 할 필요는 없습니다.
SELECT user, authentication_string FROM mysql.user WHERE user='user';
--위의 명령어로 나온 값은 DB_PASSWORD의 암호화된값
--실제 비밀번호를 암호화 한 값 -- MYSQL 8 계열에서는 폐기된 방법
SELECT PASSWORD('application_credentials 파일에 적혀있던 비밀번호');
-- 두 값이 정확히 일치하면 application_credentials에 적혀있던 비밀번호가 DB_PASSWORD라는 증거
IP 직접 접속 차단
ip 직접 접속을 차단해야 하는 이유
- 검색 엔진이 ip주소와 도메인을 서로 다른 사이트로 인식할 경우 중복 컨텐츠 문제가 발생할 수 있습니다.
- 보안상 불필요한 노출 방지 – IP 기반의 무작위 공격의 타겟이 되지 않기 위해
- ssl 인증서 오류를 만기 (아이피로 접속이 되는 경우 인증서가 동작하지 않아 위험한 사이트로 분류됨)
sudo vi /etc/apache2/sites-available/000-default.conf<VirtualHost *:80>
ServerName 아이피
DocumentRoot /var/www/html
# Reject direct IP access with a 403 Forbidden error
Redirect 403 /
</VirtualHost>sudo vi /etc/apache2/sites-available/default-ssl.conf<VirtualHost *:443>
ServerName 아이피
# Reject direct HTTPS IP access with a 403 Forbidden error
Redirect 403 /
</VirtualHost># 아파치 문법 검사 (Syntax OK 꼭 확인)
sudo apache2ctl configtest
# 아파치 서버 재시작
sudo systemctl restart apache2데이터 베이스 내용 치환
better search replace 플러그인 설치 후 활성화
이 부분은 화면이 정상 출력되더라도 mixed content오류가 발생할 수 있으므로 필수로 해야 합니다.
워드프레스 SSL 설치 후 생기는 MIXED CONTENT 오류 해결 방법 정리 이전 글에서 내용을 자세히 다룹니다.
검색하기: http:워드프레스처음설치시ip
다음으로 교체: https://도메인.com
을 입력하고 검색/바꾸기 실행 버튼을 누릅니다.
(테스트 실행으로 실행에 체크를 해서 테스트 먼저 하는 것을 추천합니다.)
워드프레스 처음 설치할 때의 ip가 기억이 안나면 f12를 눌러서 mixed content 오류 목록을 확인하면 됩니다.
워드프레스 처음 생성할때 모든 주소들이 ip로 만들어 졌고 그 상황에서 마이그레이션을 진행했기 때문에 대부분의 이미지의 주소가 ip로 설정되어 있습니다. 때문에 위의 플러그인으로 아이피를 바뀐 도메인 주소로 치환을 해주면 완벽해집니다.
아이피 구조로 바뀌었기 때문에 이 상태에서 이 전에 했던 고유주소(Permalink) 재생성을 한번 더 해주면 완벽하게 끝납니다.
플러그인이 설치 안된다면? (FTP 정보 입력창이 뜰 때)
이사 후 플러그인을 설치하려는데 뜬금없이 FTP 자격증명을 요구하는 창이 떴습니다. 워드프레스가 보안 검사를 깐깐하게 해서 발생하는 문제로, 아래 코드를 심어 해결했습니다.
터미널에서 워드프레스 루트 디렉터리로 이동한 뒤 설정을 열어줍니다.
FS_METHOD 설정
먼저 wp-config.php 파일을 엽니다.
cd /var/www/html
sudo vi wp-config.php파일 맨 아래 줄에 아래 코드를 추가하고 저장합니다.
/* 파일 직접 쓰기 허용 (FTP 우회) */
define('FS_METHOD', 'direct');이 코드를 넣으면 워드프레스가 파일 시스템에 직접 접근할 수 있게 되어 FTP 창이 더 이상 뜨지 않습니다.
디렉터리 권한 체크
플러그인 설치 문제를 해결하고 권한도 한번 점검해봐야겠다 싶었습니다. 업로드, 플러그인, 테마 관련 디렉터리들을 먼저 확인해봤습니다.
업로드 관련 디렉터리 확인
ls -ld wp-content wp-content/plugins wp-content/themes wp-content/uploads조회 결과, 모든 핵심 폴더가 drwxrwsrwx 즉, 숫자 777 권한으로 완전히 풀려 있었습니다. 세상 모든 존재에게 읽기, 쓰기, 삭제 권한을 준 최악의 보안 상태였습니다.
cd /var/www/html
# 하위 디렉터리(폴더)들은 안전한 2775 권한으로 변경
sudo find wp-content -type d -exec chmod 2775 {} \;
# 하위 일반 파일들은 안전한 664 권한으로 변경
sudo find wp-content -type f -exec chmod 664 {} \;#제대로 바뀌었는지 확인 drwxrwsr-x 775로 나오면 정상
ls -ld wp-content wp-content/plugins wp-content/themes wp-content/uploads
#파일도 제대로 바뀌었는지 확인 -rw-rw-r-- 664로 나오면 정상
ls -l wp-content | grep ^-
최상위 html 디렉터리 보안 확인
내친김에 워드프레스의 대문 역할을 하는 최상위 html 폴더도 안전한지 확인해 봅니다.
ls -ld /var/www/htmldrwxrwsr-x 정상
wp-content 확인
cd /var/www/html/
ls -l wp-content확인 결과, 다른 폴더들은 모두 admin www-data로 잘 잡혀 있는데 특정 플러그인과 언어팩 관련 폴더들만 소유자가 www-data로 꼬여 있었습니다.
꼬여있던 녀석들:
drwxrwsr-x www-data www-data ai1wm-backupsdrwxrwsr-x www-data www-data jetpack-wafdrwxrwsr-x www-data www-data languages
sudo chown -R admin:www-data wp-content/ai1wm-backups
sudo chown -R admin:www-data wp-content/jetpack-waf
sudo chown -R admin:www-data wp-content/languageswp-config.php 확인
마지막으로 워드프레스에서 가장 중요한 데이터베이스(DB) 정보가 담긴 금고 파일, wp-config.php를 확인했습니다. 원래 정석 보안 규격은 -r--r----- (440) 또는 최소 -rw-r----- (640) 이어야 합니다.
ls -l wp-config.php확인해 보니 -rw-r--r-- 1 root www-data ... 상태였습니다. 소유자가 시스템 최고 권한자인 root로 잡혀 있고, 권한도 644로 지나치게 널널했습니다. 바로 소유권을 찾아오고 꽉 잠가주었습니다.
# 소유자를 root에서 admin으로 변경
sudo chown admin:www-data wp-config.php
# 외부인은 읽지도 못하게 644 권한을 640으로 꽉 조이기
sudo chmod 640 wp-config.php모든 공사가 끝나고 나면 내 워드프레스 서버는 아래와 같은 철통 보안 상태가 됩니다.
- 최상위 폴더:
admin www-data소유에2775(drwxrwsr-x)상태 - wp-content 폴더 및 하위 파일: 낙오자 없이
admin www-data소유로 통일, 폴더는2775/ 파일은664 - 핵심 config 파일: 소유자는
admin, 권한은 완벽한 격리 상태인640(-rw-r-----)
이렇게 설정해 주어야 나중에 SFTP 작업할 때 Permission Denied로 뒷목 잡는 일이 없고, 외부 해커로부터 내 소중한 블로그를 안전하게 지킬 수 있습니다. 마이그레이션 직후라면 꼭 한 번 수동 점검해 보시길 권장
결론
.htaccess → 644 또는 664
wp-config.php → 640
일반 파일 → 664
디렉터리 → 2775
마지막 체크리스트
- □ 도메인으로 접속 시 SSL(자물쇠 아이콘)이 정상적으로 보이는가?
- □ 게시글 클릭 시 404 에러 없이 정상적으로 표시 되는가?
- □ 게시글 이미지가 정상적으로 표시되는가?
- □ ip로 접속 시 403 에러가 뜨는가?
- □ 홈페이지 게시글에서 f12를 눌렀을 시 mixed content(혼합 콘텐츠)오류가 없는가?
- □ 관리자 로그인 가능한가?
- □ 새 게시글 작성 가능한가?
- □ 플러그인 설치 가능한가?
- □ 이미지 업로드 가능한가?
- □ 모바일 접속도 정상적인가?
다음 체크리스트를 모두 통과했다면 홈페이지 서버가 잘 이전되었다고 판단할수 있습니다.
