태그 보관물: lightsail

Bitnami 워드프레스를 Amazon Linux 2023으로 마이그레이션

처음 Lightsail로 이사왔을 때 인스턴스 선택에는 큰 고민을 들이지는 않았다. 제공되는 WordPress instance에는 필요한 것들이 이미 다 설치 되어 있어서 인스턴스를 하나 생성하고 기존 블로그를 import하는 것으로 모든 과정들이 비교적 순조롭게 진행된 편이었다. 문제는 이 WordPress 인스턴스가 Bitnami로 되어 있어서 세부적인 관리 작업에는 제약이 많다는 점이다. 그래서 AWS에 최적화 되어 있다는 Amazon Linux2023(AL2023)으로 LEMP를 직접 설치하고 기존의 블로그를 수동으로 마이그레이션 해 보기로 했다.

이번 포스팅에서는 AL2023 인스턴스에 LEMP(Linux, Nginx, MariaDB, PHP)를 설치하고 Bitnami에서 사용하던 데이터베이스와 자료들을 수동으로 옮겨오는 과정을 설명한다. All-in-One 같은 편리한 마이그레이션 유틸리티를 쓰지 않고 굳이 수작업으로 일일이 옮겨야 했던 이유는 All-in-One에서 띄운 오류 때문이었는데 아무런 문제가 없고, 기술적 호기심 또한 없다면 굳이 이 내용을 따라 수작업으로 옮길 필요는 없을 것이다.

AL2023 환경 구축

Lightsail에서 AL2023 인스턴스를 생성한 뒤 시스템을 업데이트하고 LEMP 패키지를 설치한다. Amazon Linux 2023은 Fedora기반으로 패키지 관리에 dnf 명령어를 사용한다. PHP8.3과 필요한 패키지들을 설치해 주고 나서 Nginx, MariaDB, PHP-FPM 서비스들을 실행해 준다.

sudo dnf update -y
sudo dnf install -y nginx mariadb105-server php8.3 php8.3-fpm php8.3-mysqlnd php8.3-gd php8.3-xml php8.3-mbstring php8.3-bcmath php8.3-opcache php8.3-intl php8.3-zip

# 서비스 활성화 및 자동 실행 설정
sudo systemctl start nginx mariadb php-fpm
sudo systemctl enable nginx mariadb php-fpm

데이터베이스 초기화

MariaDB에 WordPress를 위한 database를 생성하고 비밀번호를 설정한다. mysql_secure_installation은 여러 보안 관련한 처리를 해주는데, 사용하지 않는 기능들을 끄거나 비밀번호를 설정하는 과정을 진행해 준다.

설정이 끝나면 root user로 data base를 실행시킨다.

sudo mysql_secure_installation
sudo mysql -u root -p

wordpress database를 생성하고, wpuser사용자를 생성한 다음 권한을 설정하는 과정이다. 나는 비밀번호를 새롭게 만들지 않고 기존에 Bitnami가 생성해 주었던 database 비밀번호(wp-config.php에 있는)를 그대로 사용했다.

CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wpuser'@'localhost' IDENTIFIED BY '[사용자_비밀번호]';
GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

워드프레스 설치 및 파일 권한 설정

최신 버전의 워드프레스를 다운로드 받아서 /var/www/html/ 위치에 풀어준다.

# 최신 워드프레스 다운로드
wget https://wordpress.org/latest.tar.gz
tar -xzf latest.tar.gz
sudo cp -r wordpress/* /var/www/html/

AL2023 환경에서 Nginx가 파일을 정상적으로 제어할 수 있도록 소유권과 권한을 수정한다.

# /var/www/html안에 있는 파일들의 권한 설정
sudo chown -R nginx:nginx /var/www/html
sudo find /var/www/html -type d -exec chmod 755 {} \;
sudo find /var/www/html -type f -exec chmod 644 {} \;

# PHP-FPM 실행 그룹을 apache에서 nginx로 변경
sudo sed -i 's/user = apache/user = nginx/g' /etc/php-fpm.d/www.conf
sudo sed -i 's/group = apache/group = nginx/g' /etc/php-fpm.d/www.conf

# 서버 재실행
sudo systemctl restart php-fpm

Nginx 설정

/etc/nginx/conf.d/wordpress.conf 파일을 생성하고 아래의 내용을 추가한다. 이 단계에서 나는 server_name 항목에 “[도메인이름]” 대신에 “_”를 넣어주었고 마이그레이션이 끝나고 나서 기존에 사용하던 public IP를 새로운 인스턴스에 연결시킨 다음에 SSL을 업데이트 하는 과정에서 도메인 이름으로 변경해 주었다.

server {
    listen 80;
    server_name [도메인이름];
    root /var/www/html;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/run/php-fpm/www.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

설정 후 Nginx를 재실행한다.

sudo systemctl restart nginx

여기까지 되었으면 instance의 IP로 접속했을 때 WordPress의 설치 화면이 보이게 된다.

마이그레이션 수작업

먼저 기존 Bitnami 서버 터미널에서 데이터베이스와 콘텐츠를 가져온다.

# 데이터베이스 덤프
mysqldump -u root -p bitnami_wordpress > backup.sql

# 데이터 압축 (wp-content와 환경설정파일)
cd /opt/bitnami/wordpress
tar -czvf wp_data.tar.gz wp-content wp-config.php

추출한 backup.sql과 wp_data.tar.gz 파일을 새 서버로 전송하고, wp_data.tar.gz 파일은 /var/www/html/ 아래에 풀어준다.

# wp-content 복원
tar -xzvf wp_data.tar.gz
sudo cp -r wp-content/* /var/www/html/wp-content/

DB Import 및 연결 정보 수정

Database backup file을 import 한다.

# Database back up file import
sudo mysql -u root -p wordpress < backup.sql

Database import가 완료되면 /var/www/html/wp-config.php 파일을 열어 새로운 정보로 DB_NAMEDB_USERDB_PASSWORD를 맞춰준다.

여기까지 해서 모든 이전이 잘 수행 되었다면 기존 인스턴스에서 사용하던 Public IP 주소를 떼어다가(detach) 새로운 인스턴스에 붙여(attach)해 준다. 이 과정은 Lightsail의 “네트워크” 항목에서 진행하면 된다.

많은 가이드 문서에서 마이그레이션 이후 IP정보를 업데이트 하는 과정을 거치는데, Lightsail의 경우는 public IP를 그대로 새로운 instance로 옮겨올 수 있어서 이 부분의 귀찮은 과정을 생략할 수 있다.

새로운 HTTPS 인증서 적용

Public IP가 옮겨지고 domain name으로 접속이 잘 이루어진다면, 앞서 말했던 것 처럼 /etc/nginx/conf.d/wordpress.conf 파일의 server_name 부분에 도메인이름을 적어주고 아래의 과정을 따라서 인증서 정보를 업데이트 해준다.

인증서 업데이트를 위한 Certbot 설치

# Certbot 설치
sudo dnf install -y certbot python3-certbot-nginx

# Certbot으로 인증서 업데이트 (Litcoder.com)
sudo certbot --nginx -d Litcoder.com -d www.litcoder.com

certbot certificates 명령어로 생성된 cert와 유효기간을 확인할 수 있다.

Auto renew service 활성화

Expiration date이 되면 자동으로 인증서를 업데이트 하도록 다음과 같이 certbot-renew.timer 서비스를 활성화 해 준다.

sudo systemctl enable certbot-renew.timer
sudo systemctl start certbot-renew.timer

주의! 443은 막혀있다

인증서 업데이트 이후 HTTPS로 접속이 안된다면 443번 포트가 열려 있는지 확인해 보자. Lightsail은 2026년 현재 새롭게 생성한 인스턴스의 22번과 80번 포트만 기본으로 열려 있다. HTTPS를 사용하려면 명시적으로 사용자가 443번을 열어야 한다.

결론

다소 번거로운 과정이기는 했지만, 장기적 관점으로 봤을 때는 Bitnami의 제한에서 벗어나 서버에 대한 세부적인 제어 권한을 가져올 수 있게 되었다는 점에서 시간을 들여 투자해 볼만 한 삽질 이었던 것 같다.

Lightsail Ubuntu 20.04 업그레이드 후 ssh 접속 불가 현상

Lightsail의 이미지를 Ubuntu 20.04 LTS로 업그레이드 한 후 web 환경에서 SSH 접속이 되지 않아서 또 망했다며 머리를 쥐어 뜯고 있는데, 우연히, 당연히 안 될 거라고 생각했던 터미널 프로그램을 통한 SSH 접속은 또 되는 기현상을 발견했다. 이 대로도 나쁘진 않지만 좀 찜찜 하기도 하고 해서 좀 더 찾아 보았다.

접속 오류가 발생할 때의 로그를 보면 다음과 같은데,

$ cat /var/log/auth.log|tail
...
sshd[4528]: userauth_pubkey: certificate signature algorithm ssh-rsa: signature algorithm not supported [preauth]
...

이 문제의 해결책에 대해 아주 자세히 설명된 Use RSA CA Certificates with OpenSSH 8.2에 따르면, (Ubuntu 20.04에 포함된) OpenSSH 8.2 부터는 보안 문제로 SHA-1 기반인 ssh-rsa가 기본 CA signature 항목에서 빠지면서 이러한 문제가 발생하게 된다고 한다. 해결 방법은 CASignatureAlgorithms에 ssh-rsa를 지원하도록 명시하는 것이다.

$ cat /etc/ssh/sshd_config|tail
...
# Use RSA CA cert.
# https://ibug.io/blog/2020/04/ssh-8.2-rsa-ca/
CASignatureAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

위의 링크에서 제안하는 대로 sshd_config 파일에 CASignatureAlgorithms 항목을 위와 같이 추가 하고 sshd service를 재 실행 하고나니, web 환경 SSH가 잘 동작하게 되었다. 물론, 터미널도 그대로 잘 된다.

Lightshail Ubuntu 배포판 업그레이드 후 ssh 접속이 안된다.

망했다! Litghtsail의 Ubuntu 배포판이 너무 오래전 것이라 콘솔에 접근해서 조심스럽게 screen session도 새로 만들어 가면서 업그레이드를 했는데 끝나고 나니 SSH가 안된다. 아마도 중간에 SSH관련 환경설정을 파일을 변경할 것인지 묻는 선택메뉴가 나왔는데, 현재 설정을 그냥 쓰겠다고 했던게 문제인것 같다. 다행히 blogging service는 잘돌아 가고 있지만 SSH가 안되면 서버관리를 할 방법이 없는데…

Workaound

다행히 세상은 생각보다 넓고 인간은 같은 실수를 반복하기에 이전에 같은 실수를 한 사람의 비슷한 경험을 정보의 바다에서 찾을 수 있었다 (SSH stops working after upgrade to Ubuntu 18.04 on AWS Lightsail). 대충 Ubuntu 18.04 LTS로 올라가면서 SSH 환경설정 파일에 변경이 있었는데 메인테이너 버전을 적용하지 않으면 문제가 되는가 보다. 이 포스팅은 위의 링크에 있는 내용을 기준으로 정리한 것이다. (Lightsail 한정이고 EC2를 사용하고 있다면 아래와 같이 번거로운 작업을 할 필요가 없다고 한다)

순서 요약

  1. SSH접속이 안되는 instance로 부터 스냅샷을 하나 만든다.
  2. 스냅샷의 시작 스크립트에 ssh 환경설정을 수정하는 명령어를 넣고 새로운 인스턴스를 만든다.
  3. 잘 되면 새로운 인스턴스를 고정 IP에 연결하고 이전 인스턴스를 지운다.

스냅샷 생성

SSH 접속이 안되는 인스턴스로 부터 스냅샷을 하나 만든다. 관리 -> 스냅샷 수동 스냅샷 아래의 ‘+ 스냅샷 생성’을 클릭.

생성이 완료될 때까지 조금 기다렸다가 이 스냅샷으로 부터 새로운 인스턴스를 하나 만든다.

시작 스크립트를 추가하고 인스턴스를 실행

새 인스턴스 생성 메뉴에 보면 “시작 스크립트”를 넣는 곳이 있는데 이곳을 선택하고 ssh config를 변경해 줄 다음의 sed 명령어를 입력한다.

sudo sed -i 's/^Ciphers .*/Ciphers +aes256-cbc,aes192-cbc,aes128-cbc/' /etc/ssh/sshd_config
sudo service sshd stop
sudo service sshd start

그리고 나서 인스턴스를 실행하면 처음에는 여전히 SSH 접속이 되지 않는데, 꽤 오랜 시간 (10~20분)이 지나고 나서야 가능해 진다.

고정 IP 변경과 정리

네트워킹 -> Static IP에서 고정 IP를 분리하고 새로운 인스턴스에 새로 연결해 준다.

새로운 인스턴스를 고정 IP에 할당 한 후 기존 서버를 끄고 도메인에 접속해서 잘 돌아가는 지 확인한 후 스냅샷과 기존 인스턴스를 지워준다. 스냅샷 생성 기능은 예전에 한 번 백업용으로 좋겠다 싶어서 만들어 봤다가 추가 요금이 나온적이 있다. 🙁

결론

다음 부터는 이미지를 업데이트 하고 싶을 땐 먼저 백업을 만들어서 작업 및 확인하고 최종으로 IP를 변경 하도록 하자.